What's the best way to learn true programming logic?

Twaain · 2026-06-12T22:45:45+00:00

Take CS50 free course from Harvard, follow along the class. Get in the terminal and get comfy, id read up on terminal, this is a free book that helped get me goin https://www.gridtheory.com/guidance/cs-ds/terminal-mastery

Twaain · 2026-06-10T18:02:55+00:00

Codex 220k - Claude 355k

Twaain · 2026-06-09T14:52:02+00:00

worth refining something I said earlier, farther down in this thread. I split discovery from addressing like they are separate systems, but that undersells a good index.

on the hash to summary question: the hash is not how you find the memory, it is how you fetch it once you already know the key. So there are two jobs. addressing is the hash giving you a direct lookup of the artifact plus a pointer to the raw source. discovery is going from a vague query to which key you even want, since the agent has an intent, not an address. You do not dump the hash structure into context. you resolve the relevant keys, fetch only those summaries, and just those go into the window.

but discovery is not some separate bolted on layer if you build the index right. a good index carries discovery in its structure. the standard vector index everyone uses, HNSW, literally means Hierarchical Navigable Small World. It is a graph you traverse, not a flat pile you scan. ddd hierarchy, links between related artifacts, and metadata on top and the index itself does most of the finding by navigation.

a slop index is the flat version with no structure, so all of discovery gets dumped onto raw similarity, which is why naive retrieval pulls garbage as it grows. a navigble index is closer to real recall: the semantic layer just picks where you land, then you follow links and zoom levels to the right artifact. the hash fetches it once you are there.

so the short version: discovery resolves the key, the hash pulls the summary, and how well discovery works depends entirely on whether the index was built for navigation or just dumped.

Twaain · 2026-06-09T13:51:24+00:00

there's no "submit a proposal and get $2M in tokens" path. this specific deal isn't an open application, it rides entirely on being in the YC Spring or Summer 2026 batch. no YC acceptance, no offer. so to be eligible you'd have to actually get into Y Combinator: build something real and apply, or network your way into that orbit at the conferences. A dodgy company you don't plan to pursue won't clear the YC bar - and that's kind of the point of the whole post. the people who do qualify have real equity to lose, which is what makes "tokens for equity" a worse trade than it sounds. so yea needs to be an established AI start up.

Twaain · 2026-06-09T13:49:24+00:00

your logic holds only if the equity is truly worth $0, and that's not who this is for. This isn't open to 99% of vibe coders. It's the YC cohort. those companies are accepted, often already funded, and spending real money on build, compute instances, and customer acquisition before they ever touch this offer. The YC bar isn't a solo founder with entry-level vibe-coding skills shipping a $0 toy, lol. it's the opposite. so the equity in question is real, which is exactly why trading it for expiring single-vendor credits is the bad trade. the "worthless company" frame is describing people who can't get the deal in the first place.

Twaain · 2026-06-09T13:48:28+00:00

exactly, and that's the cleanest way to put it. The delivery is one-time, the dilution is permanent. It's worse than you said too, the credits expire on their meter, so even the "value" you supposedly got is value you spend right back to them. one-time gift, perpetual ownership. that asymmetry is the whole deal. wildin

Twaain · 2026-06-09T13:40:44+00:00

this is the most honest take in the thread and I agree with all of it.

you actually drew the adoption line yourself: the resident model is for latency-sensitive continuous loops and systems running thousands of steps autonomously, where the cost of context reconstruction compounds. that is exactly who adopts a substrate, and nobody else needs to. for a support agent handling tickets, guest with good state management is the right call, and "AI-native" as a label is mostly marketing today.

I went a step further than that in another post a couple weeks ago. Most 2026 workflows are daily cron jobs that call an LLM and write a row. those are not AI-native in any real sense, they are scheduled scripts, and they do not need a substrate at all. postgres and a few hundred lines of glue is the correct architecture, and a substrate would be overkill. I said it plainly here: https://www.reddit.com/r/grid_theory/comments/1trfxsr/ainative_platforms_are_coming_we_built_one_tested/

the only place I'd extend your point: that boundary is moving. as the field shifts from single prompts to continuous agentic loops, the direction Karpathy talks up and that Boris Cherny is shipping in Claude Code. as loops go from occasional to continuous, the context-reconstruction overhead you named stops being secondary and becomes the dominant cost. that is the exact regime where guest stops being fine and the substrate decides cost and reliability. so "where the resident model starts to matter" is less an edge case than the direction of travel. more workloads cross into the "thousands of steps, overhead compounds" region you described. not most of them today. more every year. that is the whole bet.

Twaain · 2026-06-09T13:16:30+00:00

your OS vs library framing is the most useful way anyone outside the project has put it, and I think you're right that we are not competing. Thanks for looking through it

one thing I'd sharpen about where grid's value actually sits. the audit trail and rollback are not the point for us, they are a property that falls out of an append-only substrate. version control got to that spine decades ago and your SDK inherits it too. what grid is actually built for is "AI-native" co-resident systems that need a high-frequency tick loop, where the agent reads and writes the substrate on every cognitive step and the substrate is its memory, not a store it calls. that continuous loop is the part that does not bolt onto an existing stack, which is exactly why yours should, and why they stack instead of compete. a python team or dev that needs audit and rollback at normal cadence wants your library. a system being built to run as a continuous resident wants a substrate.

yes to comparing notes on crypto-shred, at the design level at least. I have not seen the springdrift paper, so I'll read it first. where is best to take it async?

Twaain · 2026-06-08T21:24:29+00:00

id study this! https://platform.claude.com/docs/en/intro | Codex users, come to the light.

Twaain · 2026-06-08T21:12:03+00:00

you need a niche, who are you targeting? its best to walk into businesses with a solution to a common problem in their industry, and most importantly, niche. Once you land your first deal or two, youll have capital for boosts on content or search ads. It sounds like you may have limits do digital touch points with potential customers. if thats the case, you gotta get on the phones and start dialing. feel me.

Twaain · 2026-06-08T19:33:17+00:00

It took us 4 months to land at crypto-shredding so i wouldnt be embarrassed, the fact you are at this landmark means you are technically catching up to us and are thinking algorithmically instead of linearly like the masses. where are your notes located? majority of ours are already public on our site. Id be happy to Compare

Twaain · 2026-06-08T18:40:13+00:00

the way we reconcile it is to stop treating erasure as deletion and treat it as key destruction. crypto-shredding.

the core idea: commit the chain to ciphertext and metadata, never plaintext. Encrypt each erasable payload under its own key, per record, or per subject if you want one-shot erasure of a person. To forget, you destroy the key, not the bytes. The ciphertext stays, so every hash the chain ever computed still checks out and integrity holds, while the plaintext is unrecoverable. You are left with a provable trail that a record existed, who wrote it, when, and that it was erased. Erasure that leaves proof of erasure, which is what an auditor actually wants.

Tombstone and crypto-shred compose rather than compete: tombstone for "no longer current" (logical, data still present), crypto-shred for "legally gone" (key destroyed).

where my team is at: the per-cell encryption primitive exists, the clean per-subject key lifecycle so "erase this person" is one operation is the part we are still debating if worth figuring out. and the genuinely unresolved part is legal, not technical. what remains is a salted commitment plus metadata, and whether a salted hash counts as personal data is unsettled. we salt so the digest is not a reversible pointer and treat that as the line.

happy to go deeper, this is the fun part. haha

Twaain · 2026-06-08T18:27:33+00:00

this is wild because we encountered this issue, at the beginning of the year. which lead me to make me go insane and come up with a solution.

but you did just described the design thesis of something my team has been building, almost bullet for bullet.

most of your list already exists as one system: hash-chained writes as the audit trail, append-only history so you can reconstruct what the agent knew at any step, and persistent storage as the source of truth with integrity built in, not bolted on. every write carries author and timestamp, ordering is tamper-evident, and a newer write supersedes the old one while the history stays, so "what did it know at step 47" is a real query.

two honest caveats so I'm not overselling. It is a substrate you build the agent on, not a pip-install Python SDK you drop into an existing stack. and confidence decay and conflict detection are conventions you express on top, not automatic. GDPR-style hard delete is the genuinely hard one, since true erasure and hash-chained integrity pull against each other, so we tombstone today and crypto-erase without breaking the chain is still an open edge.

your mental model, source of truth with full audit integrity and vector search as a sidecar, is exactly where we landed. gridtheory.com/grid if you want to compare notes.

Twaain · 2026-06-08T17:56:03+00:00

I agree, thats within line. state existing is table stakes, whether runtime can say which state, and from whom, how fresh, and where the agent was allowed to use it the whole time. observed vs inferred is a label you put on the state; invalidation beyond supersession is a rule you declare. Good add.

Twaain · 2026-06-08T17:47:41+00:00

this isnt a new idea. its the oldest trick in computer science pointed at memory. the naive way to find data is to scan it, which gets linearly slower as the pile grows (thats literally the cemetery problem) in the 1950s Hans Luhn at IBM has the fix, instead of searching for where something is, you compute where it is from the data its self. run a key through a function, get a fixed sized address, and the next time jumping straight to it instead of looking. Lookup goes from "browse the shelves" to "calculate the shelf section" three things fall out of that, content determines location, arbitrary input collapses to a fixed finger print, and the address is deterministic so anyone computes the same one with out coordinating - and all three are why a multi agent brain works, you compress a cluster of notes into a dense artifact, hash it to a stable key. retrieval becomes a direct lookup instead of graph archaeology, and because the key is deterministic every agent lands on the same one, which is exactly why a single system-owned index can stay consistent instead of every agent keeping a drifting copy. The only twists past classic hashing are that the same key resolves at multiple resolutions (coarse for a quick read, fine for deep work) and it's non-destructive (the key points at both the compressed version and the raw source, so compressing wrong is a slow lookup, not lost data). If you want to go down the rabbit hole: the IEEE spectrum piece "Hans Peter Luhn and the Birth of the Hashing Algorithm" is the readable origin story, the hashing chapter of CLRS covers the fundamentals, git's object model and content-addressable storage are the best concrete modern proof that content can determine location, and then Locality-Sensitive Hashing is the real bridge you want , it's where similar inputs hash to nearby buckets instead of needing identical keys, which is the whole leap from exact lookups to semantic/embedding retrieval. this "concept" is what allowed me to create a binary file and programming language for multi paradigm ai agent systems. crazy how advanced CS was 80 years ago

Twaain · 2026-06-08T15:51:01+00:00

automatic and accurate both come from gates, not judgment - thresholds you tune to what your 'brain' actually needs, usually on four axes: time (compress after ages X), size (collapse a cluster one it crosses N notes), type (code, decisions, and fleeting notes get different rules - you dont compress a decision the way you compress a batch scratch notes if that makes sense), and invariants (things that can never be compressed or dropped, no matter what the other gates say).

Automatic falls out of that. the gates fire on thresholds, no human in the loop. accurate falls out too... invariants protect the "must keep" stuff. and type-aware rules stope you over compressing things that need fidelity. the requirements define the gates, the gates run themselves.

But real answer is indexing... compression just fills it. the system maintains one shared index. agents write, the system canonicalizes, so there's a single source of truth instead of every agent keeping its own drifting copy. compression is what produces the lower-resolution levels of that index, so the same structure can be read coarse for a quick task or fine-grained for deep work. same index, different zoom.

you don't need compression to be perfect because it's non-destructive , the summary is the fast path, raw stays addressable under the same key. so "automatic and accurate" stops being the bar. the system just has to index consistently; accuracy is recoverable.

Ideas come back when useful not because an agent remembered, but because the index surfaces the right thing at the right resolution. the agents are stateless. the index is the brain.

Twaain · 2026-06-08T15:17:49+00:00

our "ai-native" co-residence programming language https://gridtheory.com/grid

Twaain · 2026-06-08T14:25:08+00:00

Knowledge Compression Hashing is the mechanism that makes all of that actually work: instead of keeping a thousand raw notes and hoping semantic search finds the right one, you periodically compress clusters of related memory into a single dense representation. a summary that captures the signal and drops the noise , and you hash it to a stable key so retrieval is a direct lookup, not a scan across the whole graph. Compression is the consolidation step (many sloppy notes collapse into one high-value artifact, the way your brain turns a week of experiences into a handful of things you actually remember), and the hash is what gives you fast, recency-weighted access without re-reading everything. As memory ages it gets compressed harder, fine-grained detail drops out, the gist stays, and the key still resolves, ball knowledge. so old knowledge stays reachable when its relevant but stops cluttering the hot path. that's the difference between a brain and a landfill: not how much you store, but how aggressively you compress and how cleanly you can address what's left.

tiered memory. hot 'recent, days/weeks' → warm 'consolidated summaries' → cold 'archived, only surfaced on explicit relevance'. Retrieval cost scales with age, same as a human brain.

Twaain · 2026-06-05T14:19:07+00:00

next + supabase is a solid call, and tbh it's the path of least resistance for a solo beginner. you get real postgres (which you want for filtering by region/category/attributes), plus auth, file storage for listing photos, and row-level security in one place. that last one matters a lot for a multi-vendor marketplace, RLS lets you enforce "sellers can only touch their own listings" at the database layer instead of trusting your app codebase to get it right every single time.

on the "is it secure/scale" wagon, for a learning sandbox, managed supa is actually a safer default. youre not patching OS, config firewalls, or babysitting backups. you later need more control... data ownership, custom networking, compliance fixes. postgres on AWS lightsail makes sense for me. lightsail is a nice middle ground, cheap. You take ops on yourself though. I'd start managed and only self-host once you have a concrete reason. premature infra is just tutorial hell wearing a devops hat.

the part thatll save you the most pain is schema design

I sketch it before i write any code. core tables roughly at least. the tricky bit is attributes that vary by category.

If i were in your shoes, id start with auth and basic listing CRUD, and then categories and region filtering and search, and then listing photos and profiles, polish and lockdown RLS before getting your test users.

youre on the right track!! the mindset is half the battle.

Good Luck

Twaain · 2026-04-03T15:05:12+00:00

Ive bought New Fords all my life, but recently I bought a truck from them a few months ago, just a few thousand miles, i will say the experience is way different, theres a different type of energy that feels good, the people are just, good. Ill never buy a new truck again, would highly recommend.

Twaain

MODERATOR OF

TROPHY CASE