This is a made up example. There are no watchmakers in history called Hora or Tempus (Hora means time in Spanish, and Tempus means time in latin). People just make up stuff.

This is a made up example, among other ones in the paper, to talk about complexity. It has great points on how to tackle complexity

I've found that most stories that begin "There once..." are allegorical. (Doubly so if the following words are "was a man from ______" :p )

"Once upon a time there was a goodie and a baddie. The goodie won and they all lived happily ever after". Dead giveaway IMO.

What exactly is the issue with the story in the paper? I don’t get it. It’s not exactly “hidden” that the story is made up and just for the purpose of illustration, as it is introduced with the words:

Let me introduce the topic of evolution with a parable.

At no point in the software construction process is your source code dropped and scrambled. Even in punchcard days there was a way to punch sequence numbers in the rightmost columns of the card so you can run them through a sorter. Isn't all software built more or less incrementally?

Here's how I took it: I've worked on some projects where a great effort was spent up front to decompose the project into small pieces. As the months passed, whenever I got temporarily pulled off project to attend to other matters I found it easy to come back, since there was only a small amount of context that I needed to get back up to speed on. My SaaS business, for example — it's something I've worked at for about 6 years now, off and on, and right from the start I found it fairly easy to put aside and return to. On the other hand — my current project, Hest, is completely fucked. It's proving insanely difficult for me to break down into small pieces, no matter how hard I try, because [bogus excuses / ugh / long story]. Since there are so many things about it that interact in so many subtle ways, whenever I get pulled away from it for a week, or even a few days, (which happens frequently) I'm basically starting over again when I come back to it. It absolutely feels like trying to build a 1000 piece clock all in one go. I've resorted to blocking out large chunks of my schedule, telling coworkers I'll be unavailable for a week or two or four, planning social engagements around it, so that I can load all the context into my head and take a few steps forward before something pulls me away again.

Some projects have tightly woven interdepencies between components. Computer games are a perfect example of a very tightly bound ball of code. This is why game programmers are among the best programmers of all; the complexity that they deal with is very high. Large creative products like InDesign and Photoshop are other examples of super hard product. I would bet that to duplicate Photoshop it would take 1000 man years of work. You see a lot of products cherry-picking the functionality of Adobe's CS products, but they are usually small subsets. Hest is indeed one of these tightly wound balls of code, because fundamentally you are going forward and backwards in time, and moving from values as they mutate and flow through the code, and you are adding flow lines which are potential paths, so now you have routing issues that grow non-linearly. The animations have to stay synchronized, and not overlap too much else it becomes a big animated mess. I would suggest that you first design it for a giant monitor (at least 3k across) where space constraints don't enter into your considerations, and then after it is working okay then figure out how to squish. When you are trying to map everything at once onto the same diagram it does create interesting problems for control; it gets hard to pin down what you are clicking on when things overlap. You will likely either have to have toggling layers (like google earth), or i think small multiples running in parallel would be very clever. In other words, 3 different running copies of the same thing; with different data presented on each simultaneously. You are trying to make a visual computer here, showing results of the code not merely internal state. One of the problems with Electron and other existing tools is that they don't automatically update the screen based on model changes, and your code has to handle all the implications, and since you are moving in different directions depending on whether it is running, or you are directing it in some way via user input, it creates a lot of very nasty micro-predicates that are sprinkled throughout your program. This is one area where Beads offer some help, because it is smart enough to repaint whatever needs to be repainted, because it tracks in the runtime the dependency of a screen object; if an underlying value that was used to draw changes its value, it reschedules the redraw of that object. If you are using WebGL and redrawing on each frame, this has no value, but in a DOM-based system the less you repaint the better, and when you have 500 screen objects that interact with each other, manually calculating proper rebuild is a big mess. There is a big effort in some languages to defer calculations (lazy evaluation); however that can create very tricky problems in terms of understanding the code, as you are no longer sure when a piece of code is running, which is hardly helpful to comprehension.

@Ivan Reese take heart, you just don't know what the proper dividing lines for Hest are yet.

Thanks for those suggestions, Edward. What's cool is that some of the things you've suggested are things I'm already doing! For instance, the part of the engine that schedules evaluation and rendering tasks will use feedback from each task to decide what minimal amount of dependent work needs to be done. That helps avoid needless rendering (which is currently HTML, SVG, and WebGL all intermingled, so I do need to be careful about layout, paint, and composite — especially since my frame budget is < 8ms so I can maintain 120fps). The specific thing that I'm finding tricky is, in short, that there is a certain experience I want to be able to offer the programmer, and that requires being able to visualize execution in a really rich way, and that means I'm only able to design programming semantics that are sufficiently visualizable. The matrix of programming semantics is the 1000 piece clock — the existence of certain semantics can enable, or prevent, other semantics from being viable, and I want to have the minimal possible set of core semantics. Each new concept I introduce needs to be mapped to some visual characteristic, and the more of that I do, the less room I leave for people to define their own visual meanings (this is an art tool first and foremost). For instance, if I lay claim to "all color" or "all shades of red" to represent something about core Hest semantics, I've just taken away power that the end programmer/artist might want to define their own meaning for. Currently, I've been able to get about 80% of the way to the level of code expressivity I'm aiming for, while only claiming: points, lines, motion along paths, decorations attached to points and lines, all contained within certain regions of space. The capabilities I'm missing are: ordering/sequencing (eg: building arrays, or calling a function with arguments in a certain order) and storage (eg: variables, databases, lookup, query, etc). I'm sure I'll be able to get them, I just need to be able to explore ideas for those things while keeping in mind (A) all the existing semantics, (B) all the semantics I've tried and ruled out, (C) the things all those semantics either enabled or prevented on their own, and (D) all combinations thereof. I could easily decompose this into smaller problems if I wanted to somehow ignore or isolate semantics so there aren't all the combinations and interactions, but I don't.

@Ivan Reese it sounds like you are grappling with the right problems. My advice is to keep pushing until it gets so difficult that you are forced to rethink your assumptions. Then start over without regret.

@jonathoda makes a good point. Those last few pieces are always the ones that cause the whole ediface to collapse. In the next iteration, I say start with capabilities that broke the previous one.

I've been doing that in a small way. Objects (currently) encapsulate state and behaviour in Hest, so there's no reason they can't encapsulate semantics too, right? If I want to "start over", I can just imagine: what if the inside of some object had different rules from the world around it? Sort of like a pocket universe, or a little FFI portal to a different language. I've used this mode of thinking to play with "a Hest" that only has numeric datatypes, no notion of time, etc.

Encapsulating semantics can be a lot of fun. For example, the easy way to explain monads to the imperative programmer is that they let you override assignment

=

and sequencing

;

in a rigorous and strictly scoped way.

Got it now. Thanks. https://twitter.com/JenMsft/status/1239433074930155521

Yes!