goodpaul6

Wouldn't the example you described result in false sharing?

I don’t think it’s trying to have some magical hook, it just feels better to program than C/C++ for most of their use cases.

That being said, I find the error handling via multiple return values + or_return pretty nifty, and the vendored libraries give it a very “batteries-included” feel.

For example, you can render hardware accelerated graphics and de/serialize JSON without downloading any packages.

It looks like they only repaint when there is interaction as well (so it does sleep while nothing is happening).

However, my point with linking this library was just to demonstrate that accessibility and IMGUI are not inherently incompatible.

My point with the example I created above was that you don't have to trade away battery life in order to take advantage of the IMGUI paradigm. My secondary point was also to implement the "interactive rectangles" optimization I mentioned above (which only took a few lines of code).

While I agree with you that there are definitely tradeoffs, I don't think the aforementioned ones are necessary.

Here's an IMGUI library that's also accessible (via AccessKit): https://github.com/emilk/egui

I decided to implement it (IMGUI that only repaints when relevant interactions occur) so that my point comes across more clearly:

https://github.com/goodpaul6/imgui-power-saving-example

Of course this is a greatly simplified example, but I can see this extending to any GUI widget that can be represented with a (hierarchy) of rectangles.

I'm not sure the perf/battery life tradeoff is a necessary aspect of immediate mode UI.

  while (running) {
    event := get_next_event()
    process_event(event)
    repaint()
  }

You could just have get_next_event block until there is a meaningful event that occurs (e.g. mouse click). You could even have your UI report "interactive" rectangles to the event layer to prevent it from producing e.g. mouse move events that are irrelevant.

IMGUI is just a different API design IMO.

I get the sense that most ad-monetised social media apps are forced to show an algorithmic feed that maximises ad impressions; otherwise advertisers will just move to a platform that does.

I suspect that even BeReal will do this at some point unless they pivot to e.g. Cohost’s [1] model of paying a monthly fee.

Unfortunately achieving the network effects required for a successful social media app is at odds with the friction involved in paying for a subscription service. As such, “cool” apps like BeReal don’t stay cool for very long IMO.

[1] cohost.org

> This is not possible at all because TypeScript is a compiler

Not sure if this supports your point. Lots of compilers emit runtime type information, e.g. Golang, Java.

Interestingly, given the minimal core of the language, arrays are not built in (this is something I'm looking to change, of course).

As such, the "array" type is just an opaque type exposed via the C binding API. Given that there are no generics at the moment, this array API works with "any" values (similar to "any" in e.g. TypeScript).

Thanks! Just fixed this. Seems the "%=" operator is less useful than I thought.

I’m currently working on Tiny [0], a small statically typed programming languages which is even more minimal than Wren.

[0] https://github.com/goodpaul6/Tiny