Arc Forumnew | comments | leaders | submitlogin
1 point by breck 9 days ago | link | parent

> Wait, you're writing about "3-dimensional source code" and the dimensions aren't settled yet? That just makes me glad I didn't read your slides, and even less likely to put in the effort next time. I'll repeat my earlier comment: your MVPs are too M and insufficiently V. > How are you so sure that you won't settle on 2 or 4 dimensions? (Let us stipulate that 5 is right out.)

Sorry, the language itself is fully settled, the only question is with our hardware prototypes, we've found a way to compute with the ETN programs mapped to 2-dimensions, and a machine structure where we can compute answers with a source program mapped to 3-dimensions. But really both are 3-dimensional, the former it's just the Z-axis doesn't vary.

In the 3-D version, the first word of a node (aka the head/base/instruction/type/command), is at z 1, and subsequent words go up the z-stack. In the 2-d version, subsequent words just go up the x-dimension. They actually both offer advantages, and we'll figure out which is better I'm sure in the next year or so.

Again, this stuff is at the cutting edge of the hardware research. We're talking about a whole new type of machine architecture without registers.

> You'll need to show me these empirical studies.

Totally agree. We will.

> I haven't actually ever heard a story that accounts for 99% of bugs. Pretty much every software engineering study ends up with a much flatter profile than that. You have to do many things right to eradicate 99% of bugs.

Agreed. And to hit that 99%, we're going to need the new hardware, so that is quite far off (3 - 20 years, hard to predict). But we can hit 90% fewer with ETN software alone.

> From what I can tell, ETNs are mostly about eliminating punctuation and replacing it with indentation. Is that right?

No. Forget about the punctuation of newlines and spaces. Think about it as Cartesian coordinates. ETNs are about giving source code physical dimensions. About making sure that source code could directly be built out of circuitry. Think of ETN programs like something you could build in a Voxel editor like MagicaVoxel. Each block holds a word, which is just a number from 0 to infinity, and problems are trees of these numbers connected in physical space. Sorry if that's not clear. I think the more code and tools we build the easier it will be to understand.

> Is upgrading the syntax to ETNs all that's needed to eliminate 99% of bugs?

No. To reduce bugs by 90% (99% won't be possible until we have ETN machines) you also need well designed ETNs. Which have good FPL things like no side effects, prefix notation, DRY, good naming, good interfaces, et cetera. Great question. Working on a release shortly with a lot more tools and help on building great ETNs.

> Nail down the input space, and bugs go down because your tests fail more often.

I like that! I'm a big fan of strongly typed languages and the idea they basically prove your program correct at compile time if you think more about your types.

Thanks for the feedback! I hope the next wave of ETN stuff will help start to demonstrate the benefits better.