V and I had a great time and I appreciate him making the trip to Virginia.
One thing that has come out of the process is that I am a firm believer in the need for a "Turing Complete" environment on a DAC. The other thing that came out of the meeting is that the existing Eth. design has woefully inefficient abstraction for the types of data structures that DAC developers really need. Technically it is turing complete and it is possible to do everything on their existing design. I was throughly impressed with V's ability to solve problems on the fly and believe that Eth will be a very interesting platform and will find many solutions.
So what I can say is that a future BitShares chain will be fully Turing Complete with the ability to run arbitrary code. I think that we will probably have a friendly competition moving forward as we steal good ideas from each other.
One thing I can say is that nothing replaces real-world experience writing DACs from scratch to learn what the proper abstraction layer is. V gained some insight from our experience writing real DACs while we gained some of his experience with doing things more generally.
We also recognized that the biggest need we have is for our communities to work together rather than against one another. It is kind of like different tribes. It seems that the best way to align our communities is to have a mutual financial interest and for that reason I could see a joint venture with allocation from both sides for the development of BitShares Turing.
All of these things are probably a year or more away as we both have to focus on current systems.
For less experienced developers can you define what an abstraction layer is? Do you mean something like the standard library of C++? Do you mean something similar to classes or functions which help make writing contracts easier?
One thing that has come out of the process is that I am a firm believer in the need for a "Turing Complete" environment on a DAC.
Could you please expand more on this? In particular, what would you say is the value of adding user-generated Turing complete scripts on an existing DAC over developer-generated Turing complete code implementing new features on a new DAC (or a fork of the old DAC)? I sort of think of it like the difference between compiling then running code written in a statically-typed language vs using an eval expression to interpret code written in a dynamically-typed language. If the basic framework is going to be used again and again, it would make sense to me to just implement those features in the codebase, fork, and now everyone can enjoy it. On the other hand, if these features are unique to each particular user's situation, I suppose being able to (less efficiently?) implement the custom script on an existing DAC could be useful. But I am wondering what those use cases actually are.
So what I can say is that a future BitShares chain will be fully Turing Complete with the ability to run arbitrary code.
I do think it would be pretty fun to try out a BitShares-branded DPOS DAC that has Turing complete scripts. But I want to make sure that I understand correctly; you are not advocating that core BitShares DACs like BitShares X and BitShares DNS become "Turing complete" correct?
From a developer perspective it's definitely better to have a scripting layer. That is something Ethereum really got right before everyone else. It has to be Turing complete but there is also great difficulty is doing that in a secure manner. I can only speak for myself but I'm looking forward to Ethereum because if it's flexibility and openness which could result from it's Turing complete scripting so I hope Bytemaster builds that into Bitshares toolkit at least.
But I recognize it's actually very very hard to do in a secure manner so the challenge will be to see how Ethereum manages to do it and improve on it. In order for DACs to survive they will have to be in a continuously evolving state of growth by innovation.
Having the ability to use scripting languages to modify the behavior of the DACs through Bitshares toolkit for example would allow for rapid DAC development. That would be very good for the industry because honestly few people know C++ well compared to all the scripting languages.
When you want maximum innovation then in my opinion one of the best things to do would be to invite as many developers from as many different backgrounds as possible into the ecosystem. C++ reigns supreme for Bitcoin/Bitshares but what we need is a toolkit which can accept any language or at least all the major languages.
That way people can extend the capabilities of the toolkit over time. Ethereum seems to be in a position to take over the world once they come up with a sort of development kit. So maybe that is what Bytemaster meant by abstraction? Currently the contracts are scripts, and I can read them, but where are the libraries, classes, and what not? If it's deemed too complicated looking or if there isn't a standard library then development time takes longer.
The good news is Ethereum now has the money to make a state of the art world class development kit or standard library. In addition to that there will have to be some professional documentation as well.