First, just want to say thank you so much, zck, for taking the time to write this feedback. It is so helpful and very much appreciated!
> Can you explain what the axes are, again? The Y axis is the line; that's pretty clear. But it seems like both the X axis and the Z axis are related to how many characters into the line one goes. (Edit: I just listened to the FAQ, and the Z axis is level of indentation. So for each Y axis, there's only one possible Z value, for any number of X values? That is, you can't have both (42, 27, 3) and (42, 27, 4). Is that right?)
Sorry, this is still slightly up in the air. The Y axis is equivalent to line number (this is fixed). The X axis is equivalent to indent level (this is fixed). Still running some hardware experiments to determine whether to use the Z axis for the words and model these programs as 3-dimensional or whether to stick to just the X axis and save the Z dimension for lines connecting assignment words with their references. I realize that's still not clear and I hope to add something on hover to Ohayo soon, so you can hover over a word and see the X,Y,Z location.
> On ohayo.computer, you might want to make it obvious that you have to open the developer console to see the output from running the code. This is the last thing I would think to do. Compare it to many other "run code online" sites, e.g. https://repl.it/JtNz/0, where there's both a "run" button so I don't have to hunt for hidden menus that explain what command to press, and a box in which output goes.
> On a technical note, Ohayo's fib.fire seems to be broken for me. Every box seems to have "no block 'X' found" in it: http://imgur.com/a/fwM8X. This happens in both firefox and chrome.
I'm sorry! I'm still figuring out best practices for designing ETNs, and I've been changed the instruction words a lot. I'm currently building a suite of utilities that will easily migrate programs from and older ETN version (in this case, Fire), to a newer version. This is definitely a critical need before this thing is ready for people to depend on, and I'm sorry about the trouble now. We have made a lot of progress in figuring out some best practices for ETNs (largely by stealing the best ideas from Haskell), and one of the next big changes will be a highly improved version of Fire that implements those best practices. But even when we have a much better and more stable version of Fire, I expect there will always be room for improvement, so will get some better systems in place to ensure people don't have to worry about breaking changes. Really sorry about that. I should add more disclaimers.
> This presentation doesn't seem to answer many of the questions I have about 3D Languages. Why are they better?
I hope the new console (which allows you to run/compile just a branch or single line of your program) starts to provide some hints as to how different ETNs are, and how they enable lots of beneficial things not possible in 1-dimensional languages and 1-dimensional terminals.
> You say you expect them to have fewer bugs, but I don't see why.
Much more to come on this. Basically the thrust is that empirically 99%+ of bugs occur in extanenous parts of the code. ETNs start bringing us closer to the absolute minimum, perfect program necessary to solve a problem. We will see a huge reduction in bugs just from going to ETNs => current high level languages => machine code, however, that's just the beginning. We're inventing a completely new non-von neumann architecture, 3-d machine architecture, that can compute high level ETN programs directly. But realistically that is years away from reliability. In the short term we'll be able to realize a lot of gains in bug reduction just from using ETNs that compile to 1D languages.
> You say that they're easier to understand, but even you have a problem figuring out what the location of a given character is!
I know, very embarrassing! That one is because the Z/X axis debate is still up in the air. Hopefully the correct answer in the design decision will emerge soon.
> I want to know why you think something, not just that you think something.
A lot of it is empirical. But it's the type of thing where I can see that ETNs will be 10-100x faster because they solve a lot of unsolved problems or poorly solved programming problems, but they won't be 100x faster until all the other stuff is there too (stuff like the code editor, which we finally just added). At this point I see no deal breakers and am highly confident all the predictions will come true (and then some), but it's a matter of still doing lots of grunt work to eliminate the trivial (but impactful) road blocks. But yeah, I fully agree with your sentiment and hope we can start to provide more hard data and direct proof about why we think these things.
> And, not to nitpick, but I really don't get the whole "ETN" phrase
This is a great nit! "Extended Tree Notation" is probably better. Thanks!
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.