6 ms·

I find the content-addressed, name-independent, immutable (kind of blockchainy) approach to source code very interesting. On the other hand this seems to be rat

by nadam 7y ago

I find the content-addressed, name-independent, immutable (kind of blockchainy) approach to source code very interesting. On the other hand this seems to be rather orthogonal to other (semantic) aspects of the language. I wonder what would happen if we would change one thing at a time to test the idea: create something like unison based on an existing popular programming language. (python, javascript, java, etc...) All the syntax handling, building and version control would be done the unison way, but the interpreter would be the same as today in that popular language. The benefit would be that a lot of existing code could be transferred into the initial 'blockchain', with all the current dependency hell being solved from day one. I did not think this through deeply though... Maybe some aspects of existing languages prevent them to be handled the 'unison way'?

brodo 7y ago
I tried something like that in 2016 with Javascript. I parsed the source code and put every AST node on IPFS and linked it to the other node using the hashes. The problem was that this is a _lot_ of overhead...
- zamalek 7y ago
  Spent a year doing R&D into storing a "abstract syntax DAG" consisting of extremely rich syntax nodes (effectively entire programs/modules). That overhead you mentioned is why we decided that failure was a good result.
- capableweb 7y ago
  Interesting, you have published the results/source somewhere public? Would love to take a look at it. If you're using a language that doesn't need a AST/where the AST is the same as the source code, I'm sure we could pull out more benefits of this approach. Seems one would need a lisp or lisp-like language that is homoiconic.
zubairq 7y ago
I have done exactly that with a language called Pilot. It is not pure JS but based on JavaScript and all code is content addressable and indexed by the sha256 of the code
- ed 7y ago
  Google isn't turning up much. Is the project open source? Would love to take a look.
  - zubairq 7y ago
    Sure, go to yazz.com and click on github to see the source
mekkkkkk 7y ago
I'm guessing language purity is important when it comes to this. Translating the "unison way" to an imperative world of statefulness and random side effects could be rough.
- Too 7y ago
  You don't need it down to each function. Just having hashes this on the #include/import level of the source code would be a win for optimizing build and test of big code bases. Most build systems today just operate on file time stamps which has a lot of tricky cases where the build system gets out of sync and requires a make clean to get back into decent shape.

by nadam 7y ago

brodo 7y ago

I tried something like that in 2016 with Javascript. I parsed the source code and put every AST node on IPFS and linked it to the other node using the hashes. The problem was that this is a _lot_ of overhead...

zamalek 7y ago
Spent a year doing R&D into storing a "abstract syntax DAG" consisting of extremely rich syntax nodes (effectively entire programs/modules). That overhead you mentioned is why we decided that failure was a good result.
capableweb 7y ago
Interesting, you have published the results/source somewhere public? Would love to take a look at it. If you're using a language that doesn't need a AST/where the AST is the same as the source code, I'm sure we could pull out more benefits of this approach. Seems one would need a lisp or lisp-like language that is homoiconic.

zubairq 7y ago

I have done exactly that with a language called Pilot. It is not pure JS but based on JavaScript and all code is content addressable and indexed by the sha256 of the code

ed 7y ago
Google isn't turning up much. Is the project open source? Would love to take a look.
- zubairq 7y ago
  Sure, go to yazz.com and click on github to see the source

mekkkkkk 7y ago

I'm guessing language purity is important when it comes to this. Translating the "unison way" to an imperative world of statefulness and random side effects could be rough.

Too 7y ago
You don't need it down to each function. Just having hashes this on the #include/import level of the source code would be a win for optimizing build and test of big code bases. Most build systems today just operate on file time stamps which has a lot of tricky cases where the build system gets out of sync and requires a make clean to get back into decent shape.