The Hazel programming env is dope. I can already imagine using it to explain refactorings to new programmers.

The twisted tree diagrams is also really neat. Is that a new idea as well? I got the beginnings of an idea where it might be a good diagram to display tangled code paths.

Very nice work

Paper here: https://declarative-dragging.github.io/D2.pdf

IMO one of the remaining gaps of agentic coding is that it's hard for even multimodal LLMs to check interactive motion effects for correctness and "feel." Like, sure, they can take screenshots of a few snapshotted states, but in terms of how things react as underlying nodes move and (potentially) reflow. How do you QA the feel of moving your wrist rapidly in the context of nested zones?

The answer is that you avoid the need to: you have a (nearly-provably) correct foundation that ensures that behavior is predictable regardless of state, and just render accordingly.

The paper's approach is incredible here: simultaneous optimistic rendering of multiple possible states, and a composable algebra (a small combinator language) over how drop zones and distance are derived - allowing for an extremely high-level interface in practice. Everything feels snappy and right, and the code you write is about as minimal as you can get - though the paper notes that state management is somewhat complex. But this seems solvable!

Once this is ported to HTML, it'll become an incredible part of the modern dev toolkit. I'm very excited for what this means.

--- Does this also work when the search space becomes large? I fear this might lead to an exponential blowup.

(The examples shown are all tiny) ---

I fear this might lead to an exponential blowup.

(The examples shown are all tiny)

You have a list of sets and their subsets below them shown on screen. Now you take one element from one of the sets and add it to another set want things updated, this will trigger exponential computation. Since we (human) can't really visually look at all the exponential subsets anyway it will be not a very useful visulalization.

So exponential state space will be a problem only in the cases we don't care about it. Even then we could choose only few of the states by some criteria.

[0]: https://hazel.org/

In huge "Stop Drawing Dead Fish" / "Stop Writing Dead Programs" ways. Which I'm such a fan of. Asked Astra to chase down references on this a couple weeks ago, quite enjoyed the result. https://news.ycombinator.com/item?id=5634662 https://news.ycombinator.com/item?id=33251799 https://news.ycombinator.com/item?id=33270235 https://chatgpt.com/share/6aea25b4-e294-83e9-b925-431bb13b00...

At my very first job, we had a weekly meeting to assign tickets and estimates.

Our non-technical PM wrote "drag-and-drop" on a whiteboard, and then my name.

"Gavin, how long do you think this will take?"

"All week. At least. Maybe longer?"

PM laughed, then realized I wasn't making a joke.

"What do you mean 'all week'? That's ridiculous, do I need to give this to someone else?"

"Well, you could, but I wouldn't count on you getting it any sooner."

Appalled, he exclaims: "It's just drag-and-drop!"

After 10-15 minutes of a room full of engineers trying to explain the difficulty, he gave up with an unhappy "Fine."

The phrase "it's just drag-and-drop" became an inside joke for the rest of my time there...

Nowadays you would just "npm install drag-and-drop" but back then you often had to hand-roll solutions.

If anyone can dig up an ancient library on GitHub for drag-and-drop back in those days, I'd imagine it would be several thousand lines long, not to mention the absolute nightmare that testing something like this with a proper framework and accompanying testing library.

It's not insurmountable by any means, but it does have enormous inherent complexity compared to almost every other UI action there is.

https://donhopkins.medium.com/the-x-windows-disaster-128d398...

Myth: X Makes Unix “Easy to Use”

Graphical interfaces can only paper over misdesigns and kludges in the underlying operating system; they can’t eliminate them.

The “drag-and-drop” metaphor tries to cover up the Unix file system, but so little of Unix is designed for the desktop metaphor that it’s just one kludge on top of another with little holes and sharp edges popping up everywhere. Maybe the “sag-and-drop” metaphor is more appropriate for such ineffective and unreliable performance.

A shining example is Sun’s Open Windows File Manager, which goes out of its way to display core dump files as cute little red bomb icons. When you double-click on the bomb, it runs a text editor on the core dump. Harmless, but not very useful. But if you intuitively drag and drop the bomb on the DBX Debugger Tool, it does exactly what you’d expect if you were a terrorist: it ties the entire system up, as the core dump (including a huge unmapped gap of zeros) is pumped through the server and into the debugger text window, which inflates to the maximum capacity of swap space, then violently explodes, dumping an even bigger core file in place of your original one, filling up the entire file system, overwhelming the file server, and taking out the File Manager with shrapnel. (This bug has since been fixed.)

But that’s not all: the File Manager puts even more power at your fingertips if you run it as root! When you drag and drop a directory onto itself, it beeps and prints “rename: invalid argument” at the bottom of the window, then instantly deletes the entire directory tree without bothering to update the graphical directory browser.

> If anyone can dig up an ancient library on GitHub for drag-and-drop back in those days, I'd imagine it would be several thousand lines long,

I bet, JS devs love overcomplicating and obfuscating simple concepts. Spaghetti artist might be a more accurate job title than web developer.

  > What the hell do you need a library for?

Think of a grid of cards, and all the possible drag, hover, and drop state transitions it can be in with any other card, and the animations required to make it look nice

Now also consider that you need to persist the final state on the backend, and handle things like rejection, cancellation, failed updates/errors.

It becomes a massive state chart and web of complexity

If you are dragging within the paage, then the draggable “ghostl is your problem too. As is deciding whether the ghost should affirmatively snap out of and into the source and target containers (that is, whether the destination container should appear to “make room” for the ghost at some point), whether there’s a transition on that, etc.

Drag and drop in non-web GUIs have all sorts of visual affordances that are your job in HTML.

Okay, you've added a requirement. Poll the current cursor position after the first hit-test sets the dragging state and call a function to render what you what rendered there at a higher Z level than anything else. Your 30 minute job has become a 60 minute job.

> As is deciding whether the ghost should affirmatively snap out of and into the source and target containers (that is, whether the destination container should appear to “make room” for the ghost at some point), whether there’s a transition on that,

Most applications don't go this far, including your operating system like Windows that sets baseline UX expectations, so you're well beyond the default expectation for drag-and-drop. If someone asks you to implement drag-and-drop without specifying they want all the bells and whistles, and you respond it's going to take you a week because you're planning to go all-out beyond necessary business requirements, they'd have a valid reason to be like "WTF mate?". Also this is still pretty paltry and not a week's worth of work.

Do you remember what browser testing was like?

Remember the quirks of browsers’ different understanding of transparency, of z-index, of events, of DOM compliance?

I think the suggestion that getting it right could take a week in the context of a particular application is actually not particularly hyperbolic.

Mind you, I was doing cross-browser testing long enough ago that I am one of those people who can say they independently invented AJAX in-house.

The problem is that even without a framework, you didn’t have a blank slate (which would have been better). You had a moving target of blank slates, you had platform differences, you had drag vs touch-drag, entrenched older browsers and the simple frustration of testing on an array of real devices, all sorts.

Now, if you were talking about 2015, then it starts to get a bit flatter.

serious question, why, when people from a field you are unfamiliar with tell you that something has particular constraints in that field, do you confidently assert that you know better?

This is how I feel about global illumination. Game devs claim it's hard but they're just noobs who don't know how to write a lighting shader.

I'm not a game dev, but it can't be that hard.

If you want to splash up the "drop here" thing it's a frickin nightmare. The events don't fire when they should (e.g. mouse leave doesn't fire so it gets stuck, or you get duplicate events or missing events) so you get a bunch of flicker unless you do a bunch of debouncing and fail safes to cover all the browser quirkiness. And this is the easy drop-a-file scenario.

Doing all the stuff shown in https://www.youtube.com/watch?v=l7v-UwpsEbk I'm not sure I'd even know where to begin.

If said this way he was a jerk. So good on em for making a joke.

"Why would this take so long?" would be better.

Could mean "I didn't know you had so much stuff on your plate that takes precedence". You're giving 0 benefit of doubt to a PM who in my opinion was right to push back because for a non-technical person it's not easy to grasp why drag and drop should be so much harder than other similar impact features.

Ah and there's the rub. A PM in a software project should not be a non-technical person (because tbh what's even the point, how would a 'non-technical' person even be able to evaluate technical decisions and their implementation?)

Would you fly in a plane, or drive over a bridge that was built under supervision of a 'non-technical' PM?

The head of a space program doesn't need to be an astronaut. An admiral doesn't have to know how to swim. A PM doesn't have to know all the various engineering disciplines the project may touch.

The comment was derisive, and therefore poor leadership. Period.

It was crazy complicated.

Simple is not simple.

I wish I was making it up.

Also this approach seems to introduce new complicated concepts like "composables" and even a DSL. Probably writing custom code for Drag-and-drop would be easier that figuing out how this works. I read the page and did not understand much. For example, this phrase is difficult to understand: "Rather than programming all that visual behavior directly, you simply say, for each element you want to make draggable, which future states of your application dragging it should lead to.". Not "simply" at all.

Here the goal can be a render state and it is the solvers problem to figure out what should be there.

So you define these things very atomically, but the behavior automagically finds a valid render state (usually through converting things into a standard planner or solver language, haven’t dived into this repo yet)

> Write your interface as a function of continuous variables, ui = ui(x1,x2,...) = ui(X). When dragging an element, compute the barycentric coordinates λ₁,λ₂,λ₃ of the cursor between the three nearest dropzones. Then render by interpolating the ui parameters between their values at those three dropzones, ui(λ₁X₁ + λ₂X₂ + λ₃X₃).

It's pretty clear to me how far current models are from this being real. I'd say it's a good example of how AGI it not upon us, despite what the big labs are claiming.

Even the remarkable mathematical achievements are in some ways brute-forcing in a limited space. The space of "how could we build this better" is in an entirely different category of scale.

This is very, very cool

This is one of the more exciting releases lately in the realm of web dev