Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Queryable Executables

fzakaria.com

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Queryable Executables

#71

Post by cmrdporcupine »

embedding-shape wrote: post #50
larodi wrote: post #33

>I’m amazed how much collapses into a single domain: SQL. perhaps is more correct to say "all data, including code, is table-representable, even though being a graph" or "everything falls back to tables" or even "relational algebra is all u need", but I strongly disagree SQL being a domain on its all, and that it (all) collapses into such domain. One can collapse segment tables likewise into DATALOG, which is also a…

It's interesting how different people fall into different "everything is a hammer" perspectives. I have a bunch of people around who do the same, everything collapses into table-like structures, but personally I always end collapsing everything into a tree, one way or another. Any problem I encounter, my brain seems to just default into "Yeah, arranged this way, this is clearly just a tree", and it keeps happening fo…

A tree encodes a mandatory path or navigation to get to some piece of data. But not every piece of knowledge has a "true" path.

Whereas a relation ("table" in its crude form) can be queried and projected into many forms (including as a tree) but with multiple paths to the same data and ensure future uses are not trapped in a mandatory hierarchy. This was Codd's entire discovery and it still holds 50 years later.

Re: Queryable Executables

#72

Post by inigyou »

embedding-shape wrote: post #50
larodi wrote: post #33

>I’m amazed how much collapses into a single domain: SQL. perhaps is more correct to say "all data, including code, is table-representable, even though being a graph" or "everything falls back to tables" or even "relational algebra is all u need", but I strongly disagree SQL being a domain on its all, and that it (all) collapses into such domain. One can collapse segment tables likewise into DATALOG, which is also a…

It's interesting how different people fall into different "everything is a hammer" perspectives. I have a bunch of people around who do the same, everything collapses into table-like structures, but personally I always end collapsing everything into a tree, one way or another. Any problem I encounter, my brain seems to just default into "Yeah, arranged this way, this is clearly just a tree", and it keeps happening fo…

Data-oriented programming suggests if you can structure your program as a series of transformations over tables, it'll be fast, but if it's a series of transformations over trees, it'll spend all its time waiting for cache misses.

Re: Queryable Executables

#73

Post by inigyou »

yjftsjthsd-h wrote: post #8

> We can collapse not only a complete distribution but all the state for every application into a single file, alleviating the need for /var/ or /tmp/ or /home/ or any other filesystem. The program can store its own state in the same file it is running from, and it can do so transactionally. On the one hand: I don't think I want that. Including static content with the binary makes sense, certainly. However, storing w…

I think it makes sense for usability and it's bad for security. Imagine you put a program file on a USB stick and it just magically remembers your settings and data when transferred to other computers.

Re: Queryable Executables

#74

Post by inigyou »

layer8 wrote: post #49
MomsAVoxell wrote: post #42

Earlier quoted context omitted.

$ cp /original/binary.app /new/binary.app && /new/binary.app Makes sense to me. Also for production, I would have the app change its name by adding a datetime to the filename, indicating when it was last synchronized. This is a very appealing idea, I too hope it gets 1000% more attention and adoption.

There are applications where you want to run multiple instances but also want to have them use shared state, e.g. for their preferences (editable via their UI). Or think of an editor or something like Excel. You probably don’t want the files you edit to all be stored in the binary and require separate export/import functions for sharing, or for editing using alternative applications. And in the end, that goes for pre…

On phones we do all use the model that the data is part of the app.

Re: Queryable Executables

#75

Post by inigyou »

punnerud wrote: post #47

I build a SQLite clone in Rust with this analogy in mind, and unlike SQLite it support multiple writers by giving them separate segment in a file. Calles the programming "language" PySpell, it converts Python into AST then into RUST with a lot of cool features you can enable when the database and programming language is living in the same place. http://github.com/punnerud/mpedb

This is AI slop (until proven otherwise).

Re: Queryable Executables

#76

Post by tesnorindian »

It took me several minutes to understand how this even works. Brilliant hack of using binfmt_misc rules under hood which is like a shebang for scripts but a custom interpreter. The idea of moving the ELF byte code to the segments table and executing the web server from there is next level crazy.

Good for deployment but an accidental deletion of the binary can cause loss of both data and code. Good approach for AI harness and agents though.

Re: Queryable Executables

#77

Post by cbondurant »

The self-modifying executable that can modify itself on disk is kinda horrifying to me. In that kind of "ok yes, you have proven you can, but I really think you shouldn't" kind of way.

Incredibly impressive on a conceptual level though. If someone proposed doing this while having the executable only grab a read-only reference to itself, I think that would be a legitimately solid idea.

Re: Queryable Executables

#78

Post by ramses0 »

SQLar - https://sqlite.org/sqlar/doc/trunk/README.md

...basically `s/zip/sqlar/g` and you're not that far off.

SQLite as an application file format - https://sqlite.org/appfileformat.html

...basically instead of `*.docx`, you'd do something like `UPDATE pages SET content='...' WHERE number=1` (or something). It's a compelling idea!

CouchDB/CouchApp - https://couchapp.readthedocs.io/en/latest/intro/what-is-couc...

...about 2 decades before its time. Think mongo/redis document store with a built-in concept of offline sync + replication. Survived a bit by `pouchdb` which was slightly simplified and focused on mobile apps.

Views and indexes were `*.js` functions run on every insert/update, and "apps" were basically `*.html` + `*.js` served out of the database directly. Think `address-book.couchdb` which contained `index.html` and `index.js` (and `/admin/...` routes) which "knew" how to render + edit the data itself.

Prior to that was the glorious moment when PHP began including sqlite drivers by default and you could basically do: `php something.php mydatabase.db` and have a full/hermetic browser-app experience without needing to stand up an apache server or mysql database to connect to.

"Data that knows how to edit itself" (what was that weird new-fangled parquet data encoding format or whatever) is an AWESOME idea! Maybe Mr. McCarthy was on to something when he kept bringing up "homoiconic" (or is this "monomorphism"...)

If you're listening, I propose: `*.sqlitexe`

Re: Queryable Executables

#80

Post by rao-v »

rao-v wrote: post #13

This is deranged, and perilously close to dumb, which makes it one of the best things I’ve seen on hacker news this year. Absolutely wonderful stuff.

Oh I’m sorry to bring such a presentist idea to such a cool project, but if we ever get LLMs inferencing cheaply on consumer hardware and capable of efficient continuous learning, this insane format might be the perfect way to share your unique tamagotchi of expertise in a specific area
Post reply on HN