Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I simply don't think it's possible for human beings to write good enough software for smart contracts.

I agree, but think it's fixable. I believe we have missed a natural platform in between binary notation and computer languages.

I believe there is a 2-D dimensional binary. Simply using a grid (with an array of cells forming a line, and lines stacked on top of each other—a spreadsheet basically), we can drop *all* syntax characters. The only thing you have is your cells and your semantic words.

Not only does this make tooling and languages much simpler (which will have big network effects), but you gain new fundamental complexity metrics which may turn out to be incredibly important in designing simple, bug free systems.

I personally really like crypto but it's not one of my main interests. I have been working with some folks in the space on using these ideas to build a new type of blockchain from the ground up. I bet that the biggest blockchain in the future will be a higher dimensional one, based on Tree Notation or derivatives of the core ideas.



> I believe there is a 2-D dimensional binary. Simply using a grid (with an array of cells forming a line, and lines stacked on top of each other—a spreadsheet basically), we can drop all syntax characters. The only thing you have is your cells and your semantic words.

I fail to see how this helps.

The reason why bugs crop up all the time in software isn't because syntax is confusing. It's also not because semantics is confusing--plenty of bugs have perfectly clear, well-understood bugs. The problem is that we as programmers don't think about how our software could fail. We don't ask ourselves "could this multiplication overflow?" frequently enough. We don't look at code and ask "who made sure this pointer points to valid data?" We believe that there's no way the price of an affiliated token could ever reach exactly $0, so we assert that it can't happen.

The way you avoid these bugs is to just simply make it impossible for the system to get into certain states. It's already the case with statically-typed languages that it's impossible to pass a string to a function that expected an int. If you design your API right, you can make it impossible to get an index into an array that is out-of-range (although this is way too rarely done). But, even then, you will still find people who will confidently use the escape hatch to say "this string is clearly UTF-8, I know it is from outside experience, so don't bother checking."


Just to add, things like type checking are the comparatively easy part. The world itself and many of our constructs for thinking about it are not well defined. The trouble in reconciling these things are why things like appeals courts exist. Smart contracts built on this ill defined world will always have bugs. The world isn’t going to become significantly more well defined for smart contracts, either. If that were possible, we wouldn’t have those aforementioned higher courts.


All parts in a system have a probability of failure. A bug in a well-engineered system is only a problem when a long series of things simultaneously go wrong. Tree Notation (2D languages), can be used at all layers, from microcode to assembly to system langs to interpreted langs to user facing high level langs. It's simplicity will decrease the probability of failure at each layer of the stack, causing a huge improvement in total reliability of systems. It even works great with paper! Easy to make fallbacks for when the network goes down.


did you just reinvent Befunge, but unironically?


    >              v
    v  ,,,,,"OH NO! "@


Can you elaborate on your last paragraph or point me somewhere?


I can't yet, sorry! My general research on Tree Languages, as well as a number of products I make, is all open source and public domain, but (sadly since research funding is not so advanced) I do have to be a bit pragmatic and make some money here and there. There might be some bits and pieces out there.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: