vaughan

I find it odd that we design and understand our software as diagrams on whiteboards, and then we just maintain this big ball of text.

Everyone thinks they are writing clean code, but most projects require huge amounts of time spent poking at it to figure out what the actual core business logic is.

I think the future of programming is two-way sync between visual and code, where every piece of code is visualized in a graph. I want to open a project and see the function call graph, live annotated values from different code paths, and a data dependency graph of how every value in the system responds to events and user interactions.

Measuring software in human capital isn't a good idea. Software becomes crusty very quickly. Once you get a huge user base re-architecting becomes almost impossible without a re-write.

A lot of velocity can come from completely freeing yourself from an existing solution and it's customers in the short-term.

I wonder if something that automatically organises your code into separate files would help...and fixes all the imports for you. A cli tool that would _lint/autofix_ your code organization. And then you would just need:

- IDE plugin (VSCode, IntelliJ) to show an organized IDE file tree

- cli tool to allow browsing organized code from terminal

- perhaps a custom fs for viewing your project in Finder/terminal and easily browsing in other tools

- git wrapper to show correct file names in diff/status

- chrome extension for Github to show flat files in a structured way

Yeh this seems to be the primary problem. You would basically use uuids and end up with your files in a sort of database.

I think this often scares people because they don't know where something definitively lives anymore...and you rely on a tool to access your stuff.

Some people actually prefer a definitive location for things...in order to build a mental map to come back to things. When I am coding I know where to find things quickly based on the shape of the folder structures I browse. Folders just seem natural with many analogies to the physical world...whereas graph clouds such is with tagging are rare.

But I think we must remember that the file system is essentially a database with a tool that one relies on to access the underlying bytes on disk.

Interesting. Just made me think of using a custom filesystem to navigate a codebase. Similar to: https://github.com/osnr/TabFS. I wonder if anyone has done this.

When I need one of these packages, I search Google, and typically read their API on Github. I never navigate a hierarchy to find them.

When we make our own code flat, we have problems because we don't have an easy way to search. Another argument would be that hierarchies can help contain dependencies - i.e. don't depend on code outside of a directory.

> that doesn't mean the hierarchy of the books on the shelves is useless

I just think the hierarchy should be virtual/automatic, and the focus should be on tracking dependencies between components. I think very few people would look at dependency graphs of their codebase...there's just not good tools.

I wonder if there is already a modern tool/suite for Node/Python inspired by Smalltalk...

    import {alias, _export, _eval} from './util.js'
    
    export default async function config() {
      git()
    }
    
    function git() {
      alias({
        gpsuom: 'git push --set-upstream origin master',
        gpsuvm: 'git push --set-upstream vjpr master',
        gpsu: 'git push --set-upstream',
        gmvd: 'git merge vjpr/dev',
        gmvdgp: 'git merge vjpr/dev && git push',
        gprom: 'git pull --rebase origin master',
        gpuohm: 'git push origin head:master',
        gpom: 'git pull origin master',
        grhh: 'git reset --hard HEAD',
        gisquash: 'git reset --soft HEAD~$(git rev-list --count HEAD ^master)',
        gacp: "git add . && git commit --message 'Update' && git push",
        gacmu: "git add . && git commit --message 'Update'",
        gacmup: "git add . && git commit --message 'Update' && git push",
      })
    }
    
    function brew() {
      alias('bbrew', 'br')
      alias({
        br: 'HOMEBREW_NO_AUTO_UPDATE=1 brew',
        // x86_64
        ibrew: 'arch -x86_64 /usr/local/bin/brew',
        abrew: '/opt/homebrew/bin/brew',
      })
      _eval(`$(/opt/homebrew/bin/brew shellenv)`)
    }

Rust isn't a scripting language - too strict, no optional typing, slow compilation.

Is there actually a graph view? Or is it only the graph as a tree? I couldn't see it in the demo.

In every category you mentioned there are new products released and widely adopted all the time. Look at the rise of ClickUp for example in such a crowded space as project management.

I don't think its too farfetched to one day see a new entrant offering as a key selling point that their api is just a big interoperable graph that you can easily plug your company into...and that's not just GraphQL.

Yeh I think it's way too complex to shoe-horn in later with minimal benefit.

But new databases are being built at new companies every day. A lot of new companies I see, build out their first MVPs, CRMs, etc. adhoc in Airtable. Then some mockups in Figma. Then they bring in the devs to build a RDBMS.

Now if all these low-code tools worked on manipulating a single graph instead of building a bunch of disparate relational databases...that would be cool. And then you just need a good graph database to build web apps with.

I think a bunch of tools need to be re-invented with this in mind.

> would agree on common annotations for all kind of metadata

Thinking about a project/task manager for example. They all pretty much have similar schemas at this point. There is also a huge industry in connecting tools together. Zapier/IFTTT/Unito/etc. Everything is adhoc though or proprietary. Standardization is slow and boring.

I think the best thing would be if someone made a schema for this that gained wide adoption, and then the transformers from these existing applications fed into this graph. Basically using a graph db instead of relational or key-value.

I think a big reason for lack of popularity is familiarity of graphs in general. Most people wouldn't know of a good graph editor I would guess. Everyone knows documents and spreadsheets/tables/lists/folders, but it's rare to see a graph anywhere. Online and offline. If I have to think about an example of a graph in real-life what comes to mind is: a corkboard with strings going between them to track a criminal in a tv show, or a subway network map. In VSCode/IntelliJ, there is not one graph I look at frequently, even though pretty much all code is a data flow and dependency graph.

I think part of this is that graphs always appear like a complicated mess, and we prefer hierarchies and categories.

I would really like a tool like Airtable for graphs. You start with spreadsheets with columns relating to other columns, and then you view the graph next to it as you go. I don't know of a popular tool that does this. It's funny because behind-the-scenes of spreadsheets there is always big dependency graph that updates cells as changes come through.

All the specs feel overly-complex too. Like a relic from the XML/SOAP days. For such a simple base concept (subject-predicate-object / entity-attribute-value) it feels like overkill. It's interesting though thinking about how JSON won, while being extremely inferior to XML. Although I think this ability to move fast has left us with a ton of untyped data lying around, and plenty of ad-hoc data transformations.

I'm interested to read into the EasierRDF doc you sent - looks very interesting.

This expandable graph seems like the purest representation of all data in a company.

Instead we have several different databases each with their own schemas. All with entities related to one another, but without these relations defined anywhere, and impossible to query.

RDBMS are implementation details of this graph that involve a heap of manual work. Wouldn’t it be great if the rdbms was generated from this graph.

There are so many interconnections between the data involved in the design and implementation of a product and the product database itself.

Imagine hovering over a UI element and seeing who implemented it and when, what project it was part of, why the project was initiated, and what kpis and goals it contributes to.

Before Bun, Node+V8 was just too slow to start.

IMHO all scripts should be written in TypeScript...you get typechecking and all the rest of the editing experience. Plus things like Wallaby.js for live coding/testing.

My `.bashrc` now just runs a TypeScript script with Bun. Allows you to use proper structure instead of brittle spaghetti stuff. The number of times I'm debugging silly PATH stuff was too much...

Mito doesn't look like it keeps the flexibility of a spreadsheet in that way.

This "fill formula down/right" feature is so strange. A developer would be like: let's just set a formula for the entire column, and make it refer to another column. And let's name the columns something. Like Airtable.

But its surpringly flexible and hackable.

I wish there was something like GSheets + Airtable.

I haven't dived into the differential dataflow stuff yet. I think a lot of these projects may be handicapped though by trying to work with existing SQL queries and user SQL knowledge which makes things more complex than they need to be.

The problem is that I think a lot of people will do these big joins and serve them via graphql or a deep json object...they get all the data they need...but then to update this query may be inefficient depending on the query plan. The query plan won't optimize for fine-grained reactivity of certain parts of the result, nor does it know about other queries that will be run which prevents intelligent caching of sub-queries.

Also the SQLite bytecode engine. https://www.sqlite.org/opcode.html

Most people choose a relational db without even realizing what relational means and what the tradeoffs are.

Almost every app dev would prefer that their app reacts to changes in the entities, and updates it UI accordingly. Incrementally computing new query results. This is non-trivial in the relational model.

The relational model is a bunch of constraints such that relational algebra can be used by the system to re-arrange the query plan and get the same results.

Your queries are optimized, yes, but if you want to stream changes, then you probably want a different query plan altogether. And its not a matter of just making SQL cacheable and streamable like with incremental view maintenance - you probably want different queries to run altogether. Most people aren't building analytical reporting apps with SQL. The database size for a single user or team in most apps is such a small size that aggregations can just be done client-side even.

I think a better way would be to have a database that knows about all queries in your app, and optimizes collectively. And instead of relying on the database to do it, give users the tools to build query plans themselves. And also, throw away the idea of relations and just make all query results reference the underlying entities. Instead of complaining about the "ORM mismatch" with relations, get rid of the relations, and embrace objects.

The first example of UI frameworks is always the `counter`, but it's always the least realistic scenario you encounter. Almost every app involves retrieving state over the network, sharing state in multiple places in the app, and how this state is CRUDed.

The reality is that all state is very interconnected.

Ideally you want fine-grained reactivity for every rendered UI element, that ultimately reacts to the changes in a database in the cloud.

And every piece of state should ideally be persisted. Even things like dropdown menus and their state.

The simple solution to all this is to store all state/data in a single database on the client. Every time you render something from the database, a component should have its own "view model". And this view model should react to changes in the database.

This "view model" also shouldn't be hidden inside components. There should be one place where you can view all the view models throughout your code. And see the interconnectedness. In a visual way too.

Maybe we went off-track when we started to merge the view/model/controller in the same file. We create hierachies of views, and then they need to get their data from this view hierarhcy. But instead they should be getting their data from a central database in as few transformations as possible.

The mistake people make is trying to make components isolated and decoupled from the rest of the app as a principle. It sounds nice, in that when you work on a single component, you only have to worry about what props are being passed to it. What makes apps complex though is data transformations. Ideally you want data to be as close in shape to the underlying dataset as possible. Otherwise caching/memoizing becomes very difficult, and this is usually the cause of many performance issues.

And for debugging, we write textual pretty printers for data structures, but wouldn't it be better to have them graphically visualized.

Keep the best of both worlds.