For those interested, I wrote about my highlights from Curry On: http://jschuster.org/blog/2019/07/29/highlights-from-curry-on-2019/

This is fantastic - thank you!

Thanks for the summary, Jonathan. I very much like the detailed descriptions, especially the one for the talk of Thomas, which I did not see yet (but definitely will soon). Also, I am glad you found the moldable development presentation at least intriguing. And, thanks for the explicit concerns, too! I will address what I understood to be the issues. I’d be very happy to follow up with more details, should you (or anyone else) find it interesting. I think the crux of the misunderstandings lies in your observation that

Most of his demos seemed to be about visualizing data, but when I'm trying to understand a piece of code, I find that it's usually the algorithm that's hard to understand

. Nothing about software has an intrinsic representation because everything is just data, and data is shapeless. The representation is what we deemed important, and so the limitation is mostly in our imagination. During the demo, I actually showed a few algorithms. Just in the first inspectors, I actually showed the inner workings of two algorithms: One showed how to find the nearest neighborhood position to place a new circle in a layout. The other one was the inner rope data structure of a text editor. Both of these visualizations were shown in an inspector showing some objects. However, let’s take the latter. It is important for performance reasons for the rope tree to be balanced, and when it’s not you want to look at those cases in details. This visualization is useful exactly for that purpose. While the inspector shows the current data structure, having it update (for example, by embedding the inspector in a debugger), helps you spot the places that are worth investigating. We created that visualization exactly because we had a couple of those cases. But, later on I showed a couple of more algorithms. One was about computing price discounts. In that case, I showed an inspector visualizing a decorator pattern. Indeed, we visualized objects, but the objects reified the actual algorithm. This is the key. As soon as we want to visualize something, we need to make it first class. This exercises our design in a way that testing does not and, even though we program in a Smalltalk system, we often write declarative or functional code made out of explicit objects. And there was an example showing a kind of a workflow showing actors and messages exchanged. In order to show the arrows of how messages propagate, we reified the messages. The picture we show in the visualization was actually drawn on a whiteboard together with the business people when we brainstormed about the algorithm. Because we wanted to preserve the presentation, we ended up reifying messages as first class concepts, which then led to better debugability, too. Does this address some of the concerns? Mind you, these kind of conversations are highly precious for our team. We work like this since years, and it’s sometimes hard to convey what we learnt. So, any challenge is actually a boost 🙂.

@Tudor Girba It was a beautiful talk and I think if we go really granular (visualization of what each line is doing) and then build up some kind of primitives to stick them altogether, (think weaving together different parts of code lines together and giving them each a visualization) could alleviate how to do control flow / algorithm visualization point people raise about the talk. But really love how you think in terms of representation of resources rather than just strings that make stuff happen.

Thanks, @Tudor Girba. I'll have to take a closer look at this and learn more, so I owe you a more detailed response once I do.