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

Yon – a topos-oriented language with a content-addressed lattice heap

yon-lang.org

Post reply on HN
Print view View original

61–70 of 93 posts

Re: Yon – a topos-oriented language with a content-addressed lattice heap

#61

Post by danieltanfh95 »

mccoyb wrote: post #37
danieltanfh95 wrote: post #34

Earlier quoted context omitted.

This isn’t about whether the writer uses LLM or not at all, nor is it about respect. The core novelty it tries to introduce is not hard to understand (even if it is not really that novel). If you don’t want to spend time thinking about what interesting idea it is exploring, that is fine, but pretending or insinuating that it is a LLM problem is just lazy.

Explain away then my friend: surely your clear explanation will benefit many other readers who came away with similar confusion?

Exploring if it makes sense to use maths (or, to be precise, this particular construction) to drive content addressable content + other exploration around the memory space. IMO, no.

https://news.ycombinator.com/item?id=48436337

Re: Yon – a topos-oriented language with a content-addressed lattice heap

#62

Post by danieltanfh95 »

itishappy wrote: post #51
danieltanfh95 wrote: post #35

Earlier quoted context omitted.

There is nothing physics/metaphysics about this. If you don’t understand the terms, don’t pretend you do and write slop as a comment, it is really not that different from using LLM to generate slop.

The parent comment is not suggesting that Yon is about physics/metaphysics. Understanding is important for readers. Demonstrating understanding is important for writers of both technical documentation and internet comments, and of critical importance in the era of AI.

Understanding goes both ways. OP was just sharing something they thought was interesting. The Ted Chiang piece was horribly written logically and yet it was "written well" in prose. We should look past the writing and learn (if any) the interesting parts.

Re: Yon – a topos-oriented language with a content-addressed lattice heap

#63

Post by danieltanfh95 »

nvme0n1p1 wrote: post #38
danieltanfh95 wrote: post #35

Earlier quoted context omitted.

There is nothing physics/metaphysics about this. If you don’t understand the terms, don’t pretend you do and write slop as a comment, it is really not that different from using LLM to generate slop.

What if it's pure nonsense, therefore impossible for anyone to understand. Does that mean all criticism is "slop" and nobody's allowed to comment on it?

This is multiple logical fallacies in one comment and definitely a comment I would mark in the "pure nonsense" bin. Not all criticism is slop, but anything ad hominem (personal attacks), argumentum ad populum (appeal to popularity), or argumentum ad verecundiam (appeal to authority) is not useful.

Re: Yon – a topos-oriented language with a content-addressed lattice heap

#64

Post by solomonb »

omegafixedpoint wrote: post #58
solomonb wrote: post #42

Earlier quoted context omitted.

How does `refl` work if its not even dependently typed?

Had some edits I made halfway through, so I was a bit hasty. It is dependently-typed in that the only valid codomain of a \Pi type is the identity type, Sigma, or another Pi. You can substitute variables, so Id can contain terms, but an arbitrary Pi type like: \Pi (x : A) (y : B x), C x y is not allowed. See the Ty definition here: https://github.com/yon-language/yon/blob/aa4617ced3abc92ac53... . Id is the only const…

I respect you for taking the time to review this codebase. Personally I don't want to do that. It sounds like a mess.

Re: Yon – a topos-oriented language with a content-addressed lattice heap

#65

Post by GreenSalem »

danieltanfh95 wrote: post #60
Retr0id wrote: post #36

Earlier quoted context omitted.

What is the core novelty?

Exploring if it makes sense to use maths (or, to be precise, this particular construction) to drive content addressable content + other exploration around the memory space. IMO, no. https://news.ycombinator.com/item?id=48436337

It is not exploring anything.

It is bluntly stating nonsense, while misunderstating the basics of Leech lattices and the Yoneda lemma.

A 12 year old with a LLM could do better.

Re: Yon – a topos-oriented language with a content-addressed lattice heap

#66

Post by Retr0id »

danieltanfh95 wrote: post #60
Retr0id wrote: post #36

Earlier quoted context omitted.

What is the core novelty?

Exploring if it makes sense to use maths (or, to be precise, this particular construction) to drive content addressable content + other exploration around the memory space. IMO, no. https://news.ycombinator.com/item?id=48436337

I have a strong understanding of content addressing, memory allocation, data structures, and a superficial understanding of lattices. It is not clear how one has anything to do with the other. If there is any meaningful link or benefit, it has not been explained.

Perhaps some magical insight is waiting for me if I understand the Leech lattice better, but given PhD category theorists are also scratching their heads I think I'll pass https://news.ycombinator.com/item?id=48436251

Re: Yon – a topos-oriented language with a content-addressed lattice heap

#68

Post by amenn »

Hi everyone, and thanks for taking the time to read about Yon. I had an idea and I threw it down, and I'm refining it day by day. It's hard because I have little time, but I'm trying. Most of the concepts seem to be working, and that makes me proud of the intuition, even if it's eccentric enough to look psychotic. Better docs, cleaner and more coherent code, new benchmarks and use cases will come. But it's version 1.0: what did you expect? I'm alone in this exploration. A few answers for you trough the comments...

Re: Yon – a topos-oriented language with a content-addressed lattice heap

#69

Post by amenn »

omegafixedpoint wrote: post #30

A few notes, because this is obviously vibe coded, and does not work in many ways. 1. Yon's documentation mentions "Homotopy type theory:" > the runnable HoTT fragment is refl/pair/fst/snd These are basic features of martin-lof type theory, not homotopy type theory. The documentation makes no reference of an interval type, which is generally the way to go for decidable type-checking in HoTT without univalence as an o…

There's no wrong in vibe coding as long as you check what's the output. I can be wrong or missing the goal of course. But the work is in progress and I'm not writing a bash script for the theorem of pytagora. It's more complex and I'm studying as I go. You reviewed frontend/ast.ml, the small kernel, and concluded MLTT, but you missed frontend/cubical.ml. Thanks for the time you took to bring this critique, it will be helpful in the end.

Re: Yon – a topos-oriented language with a content-addressed lattice heap

#70

Post by amenn »

Retr0id wrote: post #66
danieltanfh95 wrote: post #60

Earlier quoted context omitted.

Exploring if it makes sense to use maths (or, to be precise, this particular construction) to drive content addressable content + other exploration around the memory space. IMO, no. https://news.ycombinator.com/item?id=48436337

I have a strong understanding of content addressing, memory allocation, data structures, and a superficial understanding of lattices. It is not clear how one has anything to do with the other. If there is any meaningful link or benefit, it has not been explained. Perhaps some magical insight is waiting for me if I understand the Leech lattice better, but given PhD category theorists are also scratching their heads I…

Still writing the docs. Content addressing is the mechanism, that is: same content lands in the same slot, equality is a handle compare. The allocator is provably extensional so distinct content never aliases even though the hash itself can collide. The Leech part: the heap is sized to the lattice's 196,560 minimal vectors, the coordinate-to-slot map is a collision-free perfect hash built from the Conway group's mm_op tables, and that fixed universe is what makes sets into 196,560-bit bitmaps with O(1) membership and bitwise ops.
Post reply on HN