Mariano Guerra 2022-03-02 17:00:02 Kartik Agaram 2022-03-02 17:28:43 Paul Biggar I'm curious how many users Dark has, and how you think about the business case for all the effort poured into bug for bug compatibility.
Paul Biggar 2022-03-02 17:37:34 Hey Kartik Agaram! Good question, one I asked myself many times during the last year 😂. In the last 60 days, 251 people edited code, and 471 canvases had more than 10 requests.
The way I looked at bug-for-bug compatibility is that each different thing could cause some edge case somewhere, and that it was hard to enumerate whether those edge cases were ok or not, without doing to work to make it bug-for-bug compatible.
There were also some secondary considerations:
Kartik Agaram 2022-03-02 17:44:32 I see, so it wasn't a direct correlation like $X of revenue that couldn't be put at risk..
Could you elaborate on how the 50ms blog post has implications for your own compatibility?
The point about learning how to maintain compatibility really resonates! ❤
Paul Biggar 2022-03-02 17:45:55 The 50ms blog post talks a lot about compatibility, and how we were enabling “deployless” and safe continuous delivery by ensuring that things never changed
Paul Biggar 2022-03-02 17:46:22 there’s a heading “new versions of Dark” in particular, but anything in the “versioning” section applies
Paul Biggar 2022-03-02 17:47:03 yeah, each edit is a “deploy” i guess (though it’s just a DB write)
Paul Biggar 2022-03-02 17:47:28 if you’re asking about the 250 number I used above, that’s total number of people who have edited, not 250 edits
Kartik Agaram 2022-03-02 17:47:33 Oh sorry, you said 250 unique people edited code. So this could be many more deployments from a customer perspective..
Shalabh 2022-03-02 19:41:05 Geoffrey Litt and collaborators have published
Building data-centric apps with a reactive relational database
https://riffle.systems/essays/prelude
My understanding of this approach is that you replace all (most of?) your data structures and ad-hoc data sync/copy code within an app with relational tables. IOW, all state (even UI state) is put in a app-wide relational database with well defined queries between tables that automatically trigger on updates. Very interesting approach.
Tom Larkworthy 2022-03-02 19:51:24 Its really cool. I just read it. This is supposed to be how you architect Firestore driven apps, they are also a local cache + live queries, but having SQL is maybe more expressive, however, they then go on to say SQL was getting in the way so maybe NoSQL is a better fit for apps? Its interesting.... in the shower today I was thinking of putting firebase as a virtual table on sqllite so you can use SQL over Firebase which would land in a similar place I think, it was interesting to see this today.
Shalabh 2022-03-02 20:02:20 Tom Larkworthy they say SQL as a language is not great for many things. I agree with that. They're not suggesting NoSQL, but rather a different language to query the same relational model.
Andrew F 2022-03-02 20:48:03 Haven't read this article in full, but generally love the idea. I really hope it's a part of the future of mainstream UI programming.
It reminds me of the Entity-Component architecture for games, which you can think of as making each "entity" in the game be basically a primary key, and hanging other bits of game logic off that ID, encapsulated in "components". (Implementation strategies are... manifold, so it's hard to give a good reference, but the best explanation I've seen of the idea behind ECS is Catherine West's RustConf 2018 keynote; I think it'll be comprehensible even if you don't know Rust)
Tom Larkworthy 2022-03-02 20:54:06 I am familiar with ECS too and its orthogonal to reactivity IMHO. The classic game loop is a bunch a systems applied to mutable lists in lockstep. Its explicitly anti reactive because in games its too easy to cause circular self-triggering loops. I love ECS for its extendability, and you could probably make a reactive ECS system, but the programming feeling is quite different.
Its very easy to connect reactive systems in unhealthy loops on the other hand....
Andrew F 2022-03-02 20:57:14 Sure, not so much the reactivity as the "app state is (like) a relational database" part. If nothing else, convergent evolution is a strong sign the idea is a good one.
taowen 2022-03-03 00:30:30 you do not need extra sqlite to turn a ui into a database, actually vue framework itself can be thought as a database, and query from vue directly, checkout my library https://vue-db.js.org/
Shalabh 2022-03-02 20:08:16 Shalabh 2022-03-02 20:09:14 Ideas I find interesting:
Firstly, the functions you run are deterministic and they run in a virtualized runtime, which freezes things like system time and random seed to ensure determinism (kinda reminded me of croquet.io). These functions are applied within serializable transactions on their db. Side note - the db schema is auto-created and extended as you start using it - you don't have to predefine it.
The second interesting thing is they store the function code itself in the same database so you get code-data consistency and can determine if a cached value is from an older version of the code. A small thing but I think it has big implications since the runtime is now version aware.
Deepak Karki 2022-03-04 20:08:59 https://conf.researchr.org/track/ase-2021/ase-2021-nier-track
Might be interesting to folks here -
The New Ideas and Emerging Results (NIER) track at ASE (Automated software engineering) provides a vibrant forum for forward looking, innovative research in software engineering. The main goal of the NIER track is to accelerate the exposure of the software engineering community to early yet potentially ground-breaking research results, techniques and perspectives that challenge the status quo in the discipline. The potential types of papers could be:
- Visionary forward looking research: exciting new directions or techniques that may have yet to be supported by solid experimental results, but nonetheless supported by strong and well argued scientific intuitions.
- Thought provoking reflections: bold and unexpected results and reflections that can help us look at current research directions under a new light, calling for fundamentally new directions of future research.
Konrad Hinsen 2022-03-06 07:49:51 Kartik Agaram 2022-03-06 17:00:35 I suspect the information age, when it arrives, will unpack a lot that we currently mix into the single word "documentation". https://diataxis.fr is the smallest baby step in this direction. As the smallest example, while working on https://github.com/akkartik/teliva today it occurred to me to ask the question:
What is the difference in privileges between "standard" Lua code always loaded by Teliva the framework, vs Lua code loaded from a Teliva app?
I have an answer now[1], but now I'm not sure where to store this information that I can be confident it will be available to someone else asking the same question.
[1] Zero difference, both nominally and prescriptively.
Nick Smith 2022-03-07 02:33:39 I take issue with the article's suggestion that "everyone knows what data is". IMO, nobody knows what data is. The term is as contentious as information itself. What's more: I posit that it's impossible to define "data" in a way that doesn't make it either a synonym for "information", or vacuous (e.g. "every atom and/or collection of atoms in the universe is data").
