I think I have always been able to have branching conversations via editing a comment.
The interface remembers both the old and new conversation thread and you can switch between them.
It seems like the new "Branch in new chat" feature mostly creates a new chat at the top level rather then the existing functionality of editing a comment and branching in the same chat.
True, but GDP is often a decent proxy for material living standards, especially across countries and over time (so long as we note what it leaves out).
I suspect by "note what it leaves out" you are referring to, e.g. unpaid work like caregiving and household labor, as well as inequality and environmental costs.
I would point out that GDP also has shortcomings in that it does not measure well-being directly (happiness, mental health, life satisfaction) nor does it account for non-economic quality of life factors like political stability, personal freedom, safety or social cohesion.
It's a simple metric to calculate, it's also gamed a lot exactly because of this assumption.
It's extremely faulty to measure general living standards, a country with expensive healthcare will generate higher GDP while having a sicker population, the same repeats for any essential service to quality of life which is fraught with middlemen, each step in the chain increases GDP. Also for shoddy construction, repairs and renovations will increase GDP.
Using GDP as a proxy for living standards is very poor.
And why shouldn't they? I would expect the components of GDP to correlate with living standards even if GDP does not measure it as accurately as possible.
Often yes, but I think we're seeing for years now that in US at least, the GDP numbers for a few years don't really match the living standard as felt by the population. That makes it a less than useful metric for purposes of measuring prosperity.
That’s not a small cycle count for a normal household.
90 × 24 = 2,160 total hours.
I sous vide now and then, about twice a week for 6 hours each, so around 12 hours a week.
That works out to roughly 15 years of usable machine time for the average person.
Photography is the same way. Most SLR / DSLR / mirrorless cameras have a mechanical shutter which is expected to last around 200k-1m activations. I've had a camera for a bit over a year. I've used it quite heavily, and my shutter count is at about 13k photos. At this rate, the shutter will probably last for 20+ years - which seems fine. If I'm still using the camera by then, spending a few hundred dollars to replace the shutter mechanism sounds totally reasonable.
I feel like you missed the point of Imba. It's not solely focused on code compression (although that does appear to be a secondary objective). Instead, Imba is all about empowering developers to create declarative user interfaces without the typical complexities that often accompany such tasks, like dealing with reactivity, signals, custom directives, v-dom, and so on.
IMO there is inherent complexity in the task of creating dynamic user interfaces and reactivity/signals/directives are different tools to deal with this complexity by imposing different mental model on top.
In any case, if Imba offers a new approach it fails to communicate this on the landing page and focuses on code compression instead. To me it reads like Imba is a re-pack of status quo approach (React + Next.js) that focuses on compressed syntax. This is actually a good thing, I just wonder, whether a new language is necessary to achieve this.
> if Imba offers a new approach it fails to communicate this on the landing page and focuses on code compression instead.
Fair enough. While it does touch upon `memoized DOM`, you're correct; it might not be sufficient for readers to grasp the full implications unless they're well-versed in these kinds of libraries. For a deeper dive, you can check out this subpage: https://imba.io/guides/rendering. BTW, I don't have any affiliation with this library whatsoever.
> I just wonder, whether a new language is necessary to achieve this.
To achieve compression, no. But to achieve DOM reconciliation without a v-dom, yes.
From what I see, it vaguely claims to create so-called ‘edit maps’ at compile time, similar to Svelte and million.js. It doesn’t say anything about the algorithm it uses to generate them and what limitations their algorithm puts on application code. I’m planning to do a little research and a blog post on ‘edit maps’, I’ll probably include Imba there too.
My neutered male cat sometimes disappeares but with exception of that one time I had to fetch him from the top of a 14m tall pine tree he always returns. My other cat (also a neutered male) never goes away for more than half a day.
That’s weird. We moved to a new house and I was surprised one morning to see the cat scratching the upper balcony door, waiting to be let in, even though he’d never used that particular door until that day. He seems to always wait by the door that’s closest to the nearest awaken human, regardless if he’s ever used that entrance.
Elixir is basically Erlang, just like Lisp Flavored Erlang and Gleam (the statically-checked language for the BEAM). The BEAM in general is a very specialized VM, which is why I used as an example, as the Julia compiler is also a very specialized platform and other languages targeting it would also be just Julia. Like Julia with s-expression, a typescript like extension for Julia that maybe would focus on different tradeoffs by reducing polymorphism in exchange for type checked contracts (but still use the same machinery and ecosystem since it would compile to Julia/Julia IR). I really wouldn't expect something completely different like the JVM supports (as at this point it would be better to use the LLVM directly).
