You are viewing archived messages.
Go here to search the history.

Marek Rogalski 2025-04-16 15:06:48

I've spent a considerable amount of time now figuring out in which "direction" do memory addresses mentally increase. I'm trying to pick a convention for presenting memory in Automat that would make it easier to mentally picture what's happening. No direction is perfect and each one involves some friction when mentally manipulating order of things.

The established conventions that I know of are:

  • Text goes right and down (when lines wrap). Text direction may be pretty much arbitrary when different scripts are involved.
  • Bits increase towards left (because << shifts bits up) and then up (because of "higher" bytes). Computer science courses teach that "stacks grow down".
  • Numbers increase towards left (more significant digits go towards left) but for a typical (little-endian) CPU more significant bytes are written towards right.
  • Points on a cartesian system tend to increase first towards right and up.
  • In nature things usually grow up.
Jason Morris 2025-04-16 15:11:48

I think we have no widely shared real-world experience of one-dimensional things other than maybe time. Can subsequent addresses be "later"? 😅

Denny Vrandečić 2025-04-17 08:39:22

You can "grow up" and you can go "deeper", as you can say you can go "right" on latin text or "left" on arabic numbers or both. The only constant is "away".

Denny Vrandečić 2025-04-17 08:39:29

(And time, I really like the "later" answer)

Andrew F 2025-04-17 15:33:35

The only universal answer: a spiral with zero in the middle. I kid, mostly.

For UI about memory, I would honestly go with the conventions for other UIs about memory like hexdumps, where smaller-numbered addresses are at the top of the page and proceed down, usually with a little bit of LTR or RTL within 16 byte blocks or so (possibly worth localizing?).

Unless you really want to innovate the UI, in which case do whatever. They're just numbers. You can use any consistent ordering, and they've all been used for something, so there's not a firm precedent. I think bringing in endianness, 2d cartesian coordinates, etc is a bit of a red herring. I'd only caution that trying to have numbers that grow up and sideways like a cartesian graph will be really confusing, just because if it's embedded in a UI that reads topdown/LTR like English, it'll be really hard to avoid applying that to the memory UI too.

If you want to do something weird, I guess there's also the good ol' space-filling curve visualization; that'll keep things compact without privileging any direction or even either end of the ordering too much, at the cost of, well, being weird.

Marek Rogalski 2025-04-17 16:37:48

binvis.io uses the last one for reverse engineering (and it works wonderfully there!). Memory in this view feels a little like a long noodle squeezed into a container 😂

xyzzy 2025-04-17 13:55:29

tomasp.net/blog/2015/library-frameworks

A good comparison can be Qt vs Skia.

I agree with most claims of this essay. However, having used many frameworks and after having analyzed why they work well, it boils down to.

  • Good documentation
  • Multiplatform abstraction behind a standard interface
  • Combine many calls into a simple end point (button->draw in Qt vs drawing a button via Skia)

If these are addressed by libraries, then libraries with simple callbacks are much more preferrable to frameworks.

One problem which frameworks and libraries don't address or hide away is state machines.

An app is fundamentally event loop + state machine.

Any framework that you use long enough, you will want to peek into how it is actually handling events and customize it.

📝 Library patterns: Why frameworks are evil

This article continues my mini-series on functional library design. Previously, I discussed why your library should provide multiple levels of abstraction. Today, we look at composability and avoiding callbacks. These two often go together - frameworks are based on callbacks and are not composable, while good libraries avoid callbacks and compose well.

Tom Larkworthy 2025-04-17 17:36:27

I think frameworks can change the programming model whereas a library cannot.

So a runtime like Akka is really a framework (note also has a state machine abstraction) , but there is no real way you can add the actor model without giving up execution control. Similarly, React gave a declarative programming model to the imperative DOM. Not sure if its possible as a library (it kinda of is a library until you hit the JSX bit)

Programming languages don't compose either. I see frameworks as a less drastic version of a language change. They can fundamentally change the whole programming model. They change a programming language into a different programming language, but without changing the syntax (React did change the syntax too tho) or access to the ecosystem libraries.

So sometimes a thing needs to be a framework, but you should use the least powerful thing to achieve your needs. If it can be done as a library then do it as a library.