"There's a mirage when you first look at it, like with a lake. What you see is just the surface of the lake, and that's a two dimensional view. But when you put your hand in, you find that there's depth to it. It's not just one dimension or two, but a three dimensional design." -- Carl Sassenrath on Rebol, 1996 (https://web.archive.org/web/20000830133509fw_/http://www.lin...)
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.)
> empirically 99%+ of bugs occur in extraneous parts of the code
You'll need to show me these empirical studies.
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.
> ETNs start bringing us closer to the absolute minimum, perfect program necessary to solve a problem.
From what I can tell, ETNs are mostly about eliminating punctuation and replacing it with indentation. Is that right? If so, is your claim that "99% of bugs" are hiding in the punctuation?
Is upgrading the syntax to ETNs all that's needed to eliminate 99% of bugs? What about DRY? The value of good interfaces? Parnas's theory of information hiding? SOLID?
I'll trade my pulled-out-of-my-ass theory for yours. I think bugs arise because our representation of algorithms ("code") over-emphasizes the rules the algorithms performs, and under-emphasizes the input space that the rules are meant to operate on. Bugs arise when people modifying the code forget about rare areas of the input space, and the scaffolding around the project is unable to remind them. Nail down the input space, and bugs go down because your tests fail more often. You won't fix this problem no matter how much you tweak the superficial syntax with which you write code. (I work on this, so it was not pulled out of my ass just now: http://akkartik.name/about; https://github.com/akkartik/mu)
> 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.
Strange, I had just restarted it early in the day. (And that's what I had to do just now.) It used to stay on for weeks or months on average before konking out. Perhaps it was a fluke today but we'll see if there's something that's repeatedly interfering with it being allowed to run.
Hi Evan! This thread reminds me that we had an email discussion back in 2014 about how tryarc is hosted, and whether we can provide separate sites for Arc 3.1 and Anarki. You even gave me access to the repo, but I never did anything with it :/
I'm looking at the repo now. I wonder if we could host it on Github pages. That would be the easiest and most future-proof approach. Lately I try to host new repos away from Github, but for now it may be best to have all these related projects in the github.com/arclanguage Org. Improved discoverability.
As a first step: how do you feel about making the repo public? ^_^
Yes, I recall our email thread and I saw your email on there today, which I'm copying here in case other people are interested:
> I'm curious: how do you run things on your Linode? For example, I can't find the top-level html page in the repo. It seems like the repo runs inside an iframe of the "REPL" tab? Could you provide some instructions and peripheral config files (Apache/Nginx, etc.) to help make it turn-key? I don't want to make it onerous, but I think just a couple of lines and copy-paste will go a long way.
So responding to your forum comment above and this, I would love for Try Arc to run purely client-side on a static site host like GitHub Pages. Unfortunately, as you mention here, it runs on a VPS (Linode) instead. The reason is that it's not all client-side - it actually communicates with an system arc3.1 hosted on the server.
As for making the repo public, I think that is the logical (almost) next step. The only thing preventing me from doing that right now is a security concern. Try Arc isn't the only project I have hosted on that VPS. Currently there's a measure of "security through obscurity" that helps protect the other stuff on that server. I think the next step is to move it to a server where it's the only thing running. Then as soon as that's done I'll make the repo public.
I'll respond about the iframe and other configuration a bit later.
> So responding to your forum comment above and this, I would love for Try Arc to run purely client-side on a static site host like GitHub Pages. Unfortunately, as you mention here, it runs on a VPS (Linode) instead. The reason is that it's not all client-side - it actually communicates with an system arc3.1 hosted on the server.
Though it's hard once again to understand. When are two nodes coincident? By definition you can only have one character in one place on the screen. Is he talking about indentation, that the same level of indentation can mean different things? That seems true of ETN as well, from what I can tell.
The pencil scratchings on the screenshots don't help either.
Sorry, the lines in the geometric mapping of the source code are coincident. In drawing B) in the visual proof, the edges which connect the child nodes to their parents intersect and/or are coincident. So when you put Lisp source code onto graph paper, and draw boxes around the nodes, and line segments for edges, it shows why Lisp source is not a geometric language (I define a geometric language as one where there are no intersecting or coincident line segments).
Now, figure A) shows the same Lisp code, formatted differently, in a way that is a geometric language. But as you can see, that code is standard TN/ETN. Or perhaps another way to put it is ETNs are just Lisps with a whitespace syntax and no parentheses. Another reader on HN pointed me to I expressions (https://srfi.schemers.org/srfi-49/srfi-49.html), which I hadn't seen before and is 90% of the way there to TN and ETNs. The creator of I-Expressions have communicated briefly over email now and are going to be talking soon.
Anyway, perhaps another term for Tree Notation/ETNs is "Geometric Lisp", or "2-Dimensional Lisp". I'm not wedded to the terms TN/ETNs, although I do think it's better to have new terms, because I think these will come to dominate the usage of Lisp.
Still working on more updates and evidence on why I think these will be so big.
I thought all the emphasis of how great it was made it harder for people to understand _what_ "it" was. Probably a good idea to keep an initial post like this matter-of-fact. Motivate it with just one simple strength that's easiest to communicate. Describe the broader context and implications in a separate post, later, after people understand what it is.
I totally agree. Although perhaps I wouldn't have gotten as much feedback had I taken a more modest approach? Hard to say. I still haven't done a good job communicating the benefits of ETNs yet, stemming from their 2D/geometric nature. Almost got version 1.1 of Ohayo done which makes another step toward that.
That motivation makes sense. Bear in mind, though, that the "less modest" approach has a limited amount of gas. It will stop working at some point.
I can relate with having these questions and considering the different strategies as well. If you really think that this is going to be your life's work, it's reasonable to burn some 'reputation' to get the word out. However, I've often been wrong before. Now I tend to err on the side of playing a long game.
Over time I've gained respect for the essential wisdom of this quote:
"We knew that Google was going to get better every single day as we worked on it, and we knew that sooner or later everyone was going to try it. So our feeling was that the later you tried it, the better it was for us because we’d make a better impression with better technology. So we were never in a big hurry to get you to use it today. Tomorrow would be better." -- Sergey Brin, as retold by Seth Godin in "The Dip"
Applicable to ideas like here just as much as products.
Wow, what a quote! That's exactly how I feel about Ohayo. That seems like a better approach--not to be in a big hurry to get people to use it today. Thank you akkartik. Really appreciate that advice!
My only concern pre-launch and announcement, was that I was going to get hit by a bus and the world would have to wait longer for someone else to stumble upon (and popularize) TN and ETNs. Now that it's out there and a few thousand people have seen it, I can take this more sensible approach.
Btw, just pushed version 1.1.0 if anyone's interested.
UX still needs work, but I rushed adding a "3D block" to the flow language, (using the vis.js library), so you can start to see what "3D" code looks like.