# Panel: Development Frameworks - Channel: [Devcon](https://streameth.org/devcon) - Date: 2018-10-07 - Duration: 35:55 - Watch: https://streameth.org/watch/yt-oWFUT29BhBk - YouTube: https://www.youtube.com/watch?v=oWFUT29BhBk ## Description Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/3/development-frameworks Andy Milenius, Conor Svensson, Yann Levreau, Jack Peterson, Piper Merriam, Nick Dodson, & Iuri Matias discuss Development Frameworks. Speaker(s): Andy Milenius, Conor Svensson, Yann Levreau, Jack Peterson, Piper Merriam, Nick Dodson, Iuri Matias Skill level: Intermediate Track: Developer Infrastructure Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 3 was held in Cancún, Mexico on Nov 1 - 4, 2017 Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/ ## Transcript hello my name is Yuri Matias I'm the lead developer of the embark framework I caught her other tools as well such as ether same which later got turned out into what you no no no as a test RPC this is the frame this is the frameworks development frameworks panel and also discuss tooling we're going to start by asking the panelists to give a brief introduction about themselves and also to tell us what you have been up to this past year Jack Peterson I'm the lead developer at augur and spent the last year literally the entire year developing augur and I'm happy to say we just we just sent our contracts out for their final security audits so those Thanks and so those come back with green light then launch so that's what it's meant literally always I want hi my name is Andy millenias and weed developer with bebo good to see you all I'm a developer with DAPA so we are a self-organizing network of developers who focus on the root problems of DAPs and we mostly make developer tools and other forms of blockchain infrastructure we have some command line tools that make your life a lot easier when you're working with the solidity compiler and the etherium api and we have a standard library approvable standard library of smart contracts that has been written with an eye towards formal verification which we also have some specialists working on in the background as you just saw me but screw it hi I'm Nick Dodson so I'm a senior dev at consensus and I've been working on a project for a while called boardroom originally I was working on wave fund for a while which some of you may know but I kind of stopped doing that because crowd sales are just exhausting I can't take it so and doing hjs and a few dev tools and floating around for quite some time so it's me everyone I'm Conor Svendsen I'm the author of a library called web 3 J which is the Java and Android library for integrating with aetherium it provides full JSON RPC implementation that then also smart contract wrappers so you can work with smart contracts directly from native Java code and sports track offline transactions signing all the filters and everything else I'm also the founder of a company called blk dot IO which is building our tooling on top of aetherium and core and focused really on making it a lot simpler for companies and people who want to work with blockchain technology but a less technical to kind of make sense of what's happening because right now really you kind of need to be a developer who understands IBM byte code in order to make sense of what's happening and we're we're trying to address that hello yeah so Ian Loveall I'm working on a mix developer of he mix so he mixed a mix is web ID web-based IG where we can write math contract and run smart contract as well so this tools is mainly focused on debugging features so you can run and debug transactions and also called analysis so yeah we have started this tool like one even alphago and we are in states where it is used by many people but we still have a lot to do and we hope we hope that's in maybe one year or we can have some it is now but we still have so much to do things hi I am piper Miriam I am the lead Python the Python team lead for the etherium foundation and I am building out the Python tooling ecosystem for aetherium developers sort of a three-pronged thing with lip 3py which is a counterpart to web 3gs which you guys heard about a few minutes ago populous which is a development framework for smart contract developers and then related to those is the package management and Ethier packaging up smart contracts the tooling to support that effort so development tools are often created to address certain needs or to overcome certain obstacles could you tell guys tell is what's your origin story of sorts why did you create your tools what circumstances led to that ok I guess I'll start well I guess most of the tools that we've created have the same origin story which is just that when we got started there really weren't any tools so by and large we ended up rolling our own stuff yeah that's pretty much the long and short of it so I think jack is right when it comes to the command-line tools definitely but a point to add as specifically as it relates to our smart contracts library we wanted to make something that was generic and something that was repeatable and something that would benefit the entire ecosystem and something that's easy to share and when we solved these problems we didn't want to solve them in bespoke ways that would never be useful again so a lot of what we've been doing over the last two or three years has been thinking about what is thinking about striking a balance between being sufficiently generic and repeatable and useful but not spending all your time on this and actually moving forward with your application and and not getting lost on imagining far-flung visions of the future about how these things will be used that was great yeah anger and frustration and sadness and like days of confusion and like questioning my own personal identity and why was doing this yeah and and essentially so was the dev tools I created with ejs was just I got pretty frustrated with web 3 and just wanted to do my own thing that worked for me which is good and a bad thing and then with things like eat deploy I just wanted my contracts to deploy like I just wanted to deploy them a specific way and do it in a sequence and get the data at the end of it so yeah that's definitely my journey and like when I was initially starting like way back it was like remix was like a C++ client and like there was nothing and like web 3 kind of worked and the node kind of work but like things didn't really work either and like so it was just like any sort of comfort you got from building the dev tools I think that's just like yeah it's like a sanity check almost so yeah for me it was kind of a bit of a disconnect and that's there was all this noise in the media about you know blockchain blockchain blockchain and big enterprises using it I'd spent the first part of my career working in large enterprises building on top of the JVM and really I saw a clear gap there in terms of you know all these enterprises want to work with this technology but then in the etherium ecosystem at that point all you had was a theory MJ which was a client but you didn't actually have the tooling for integrating seamlessly with the JVM ins you know the goal there was just to address that gap yeah so for this to remix I would say that we have started a long time ago to work on it and before the name was mixed and the reason why we did that is that from the beginning beginning we will need to be able to develop transactions so the first use case of mix and now remix which is the latest version is just to debug stuff and we will need this from the beginning so it was kind of yeah intense where we started to build remix to debug transactions and continue the theme solving problems that I had during development the populous was the original piece of code that I wrote and if you look at almost every other library that has shown up from me in the etherium ecosystem it was ripped out of populist and turned into something generic but every single one of those things was to solve a problem or to fix something that I needed in the developer workflow which is common thread here we were living off the land back then so a lot of tools that we develop are in different platforms so that they don't overlap but in some way I consistent especially the JavaScript one there's a lot of competing tools so our important is that diversity are we better off all focusing in in one tool for each ecosystem and make it the best we can or or is it better to to focus to devote several competing tools and try different different approaches I think having a lot of different tools is really valuable especially because we're not all unified by a programming language in the same way that you are and like the JavaScript ecosystem for instance so like for instance I our tools work really well from the command line and from bash and that's kind of how they developed with this like UNIX design philosophy but from the command line and his tools are designed from JavaScript right and so people who like to use JavaScript can use his and people who want to use the command line can use ours and so there's like different ways to approach the same blockchain we're all coordinating around a blockchain boot the way that we approach it could be completely different can I continue yeah I'm okay with you and if I want just to add a small thing I think when we think about libraries I think it's very important to be able to have a good edition of libraries and I've good experienced developer that can review libraries and he needed to have a lot of libraries but it's really needed to have good libraries so it's something that we should improve I don't have so much solution but yeah I think it's really important I was just gonna answer that as well I think that there's a certain things though that can certainly help in this regard and that's you know if the library developers making sure that their codes modular push like individual artifacts out there and you know there's been a lot of movement in this space but it's encouraging that that reuse because there's a classic problem where people see a library and it doesn't quite do what they want to do so then maybe they'll go and write it from the ground up because the library that they've seen isn't modular enough to pull parts out and so I think that that part then as well the good documentation at least it ensures that you've got strong foundations there and then people have a bit more flexibility to kind of cherry-pick the pieces that they need that do what they'd rather solve the problems that they have but then they can build on top of that rather than you know the emergence of too many you know competing versions of things doing similar things I I can kind of mirror that in a certain sense that have that there's a number of different abstractions that need to exist in every language ecosystem we need tools for ABI encoding and decoding and we need abstractions for just doing the RPC stuff and there's all of these different things that sort of do need to be mirrored and a number of these architectures are kind of already figured out things that work they're not necessarily going to translate perfectly to every language ecosystem but there's been a lot of my tooling where the JavaScript ecosystem did the heavy lifting and we just sort of copied their architecture and it has worked quite well so I think it's good that we sort of what we're seeing the same libraries across different language boundaries but I also think it's good for there to be competition of a sense inside of those language boundaries because well I don't always get the abstraction right and somebody else might come along and and have a better version of that and that's a good thing so yeah like I think I think a lot of this stuff especially on the higher layers are really straightforward like there's not many ways you can dance around a lot of these concepts like they're pretty straightforward it's just how you're going to approach handling data and then you're gonna approach you know constructing your library and I think I think the message about quality over quantity is definitely right like we shouldn't have like a bazillion crate querying layers or something in JavaScript like you don't need that like we just don't need that but I think you know building women in isolated small pieces is always a least in my mind that's been always key and kind of a motivation for some of the stuff that I did just to break it all down even if it doesn't get used like I just want to break it down to its smallest smallest pieces but also like you know then I'll do all this JavaScript stuff and it's fantastic and then I'll look at like the latest pi theorem and then I'm just like like you know it's way nicer just because it's just like you know there's no there's no depth to the code like it's literally two or three lines deep and like it's just tests and I'm like oh you know so it's just across languages I think you want to also look at what's available everywhere because there's fantastic tooling coming up from different languages at different times and like screwed just JavaScript like Java scripts great and it's accessible but like you know a Python offers a lot rust offers a lot Java if you're into Java I can't stand Java but you know some people love Java so yeah I'm not sure I'd go so far as to say javascript is great but yeah I mean I think for you know libraries in different languages I think it's completely fine understandable to replicate one library's functionality in different language within the same language I mean I think as long as if you're creating a new library if there's you know as long as it sits subtly different than an existing library and there's some new niche that it's filling then I think it I think that can be great you know I think it's good to have some degree of competition among libraries I think one thing that we have to watch out for as you know people that sometimes off the author general-purpose libraries is that we're not just writing a library because there's a quote from Joel Spolsky he's that code is easier to write than to read and I think that that's true and I think that that's that that underlies a lot of decisions that you know programmers will make regarding whether or not they should roll their own stuff and I think that that in isolation is not necessarily a good reason so the tools they this they address a lot of problems that you have but surely there's other problems that you want to solve what I'm curious about is what problems have you solved but you just have no time to implement yet the solutions I'll start so a number a number of you may have seen the package management talk from the first day if not go take a look we have a fully baked solution for package management that looks a lot like an app store if you look at it from the right angle and a lot of it just comes down to more tooling support for the spec another ERC for specifying some higher level stuff and and just well like I said tooling support and and it's not trivial there's a lot of work to be done I'm forecasting it's gonna take us the next six months to a year to really get to a point where that stuff starts to be usable but there is that force multiplier effect as as those tools the support shows up and we get Network effect across different language boundaries and and things start moving faster can I continue I think you're already right and four he mixes same thing we need any plan and we have thought about integrating the package manager and it's like it's a lot of stuff to do right of work to fix as well and then yeah it's very hard to to be fixing a point and who and to implement these things but I already do that I was thinking that's yeah there is something in remix that is quite important and we need to overcome that this is a web app and sign this web app there are different modules and there are kind of independent met but they are still packaged in the same big modules and we want and we need to speed up everything so can maybe some modules can be used inside other tools or inside was a web app I don't know what you know and this is something that's it's a nice example of for the question that we need to do we have to do we will do but we always say ok we need to do that but imagine to most of her multiples we don't have time or so on so so yeah I think the package management stuff for aetherium like it's absolutely essential it's so critical and it's so underused and I think there's a few different reasons why like even for one as I read about it and look at it like it's still not something I want to interact with yet and that's almost my fault for not making a comments about that because I definitely will but the thing is is we need to start using all that stuff if we don't you're going to have so many different issues where copying code just causes a bazillion problems and package management's really really critical but I also find that even when using solidity there's a lot of interesting dangers coming from just hidden code that's in an import so if you're importing a bunch of solidity files and you're smashing them together in a contract like sure in JavaScript if you make a mistake like maybe it could cost you your company some time or some processing whatever but if you make that mistake in contracts it's like shipping hard that's failing or failed and so we know how dangerous that is so there's a lot of interesting dynamics because in some senses I just want a copy solidity code together so I can see the whole damn thing but then at the same time I absolutely want to use a package manager and use imports because I don't want to do that because accidents happen and they certainly do so there's almost primitive things of like visibility across that system that need to be worked on but also everyone needs to chip in their opinions on why they're not using the package managers right now and what they hate about them and just go nuts like just say everything you absolutely hate about them and I think as well we probably want to study if not already because I don't know all the research that's been done on that but the NPM ecosystem and why that was so successful but then again with the NPM ecosystem like how many crappy packages are shipped every day maybe we don't want to copy that maybe we want to have something a little sturdier so this is definitely I think like a big deep conversation than that like we've just got to have because this is just not being used it's like a disaster yeah I mean we're not using a package manager at the moment but you know after this after this conference after you know you know here in Piper's talk on it I I definitely would like to start using populist I mean it sounds great to me I think that yeah I think I completely agree with the sentiment that of package managers badly needed certainly certainly beats copying pasting code like you said we've been getting by with github modules as a short term solution it's actually pretty useful but of course Nick is right package managers badly needed to the original question which was about things that we have solved in our heads but haven't had time to develop a lot of it is in the realm of smart contracts adapt up were pretty we're pretty confident pretty comfortable with the and tools that we have and they're already starting to generate interesting command-line tools on top of them but for the contracts what we really want to make is just a whole bunch of free dabs this is kind of what I was talking about in my talk earlier but we just want to make free versions of things and a lot of it is around business infrastructure so things like invoicing and payments and payroll and running our own organizational logic on the blockchain both for adapt up and for maker dough which is a project that we're very very involved in and so these are things that are fairly straightforward I would consider them solved at least in my own head and it's things that we just need to like Yuri said find the time to develop so a lot of what we want - a lot of what I want to get done in the next year is laying down the roads not necessarily building towns but laying down the roads for the logic of organizations on the blockchain yeah just realize I didn't actually answer the question as far as things that we figured out but haven't built yet one big one for us is an off chain trading system which i think is sort of the first component of how how augur is actually going to scale this is a-you know it's nothing too novel in our case it's just 0 X slash ether Delta style system where you've got you know basically someone who maintains an off chain order book and people can make and cancel orders with them and then the older matching is done on chain so we pretty much know how that's going to work we just need to sit down and implement it we I have had a solution for at least being able to show stack traces in your solidity code when something goes wrong for a while but there's pieces to be glued together and work to be done so all of these things are already the the components are there all of the pieces are there they just have to be put together I just want to say to that [Music] instead of making some random touken oriented app that like go and raise five million dollars or something and that's where you're putting your development time because raising money is like fun nowadays like easy if you can actually contribute to adapt hub or to ejs or even to web three or to these other libraries and spend your time doing that and building your reputation up as a developer and actually committing to the ecosystem that's worth so much more especially for your long-term reputation and everything just tagging yourself to a token project and raising some money is like ridiculous and like you're gonna raise all that money and it's probably gonna be and it's not gonna work so just instead you know spend your time doing something better but also like there's some great bounty systems coming up they're trying to build great experiences to do bounties and I think you know try to engage with those get coins one of them bounties networks is another and I know there's a few others eath lance and everything like engage those tools and use those try to get yourself out there and like actually submitting great pr's to things because like we really need to help because we're all inundated with crazy random at a consistent basis so one way to think about this is so I've heard the phrase the lottery is a tax on people who are bad at math startups who are doing toget launches are sort of like attacks on developers who are bad at realizing that they're probably going to be in the 99 percent who fail whereas the people on this stage have a loosely hundred percent chance of being useful so if you want to be useful consider working on tooling and we're also I know Barry protect your long-term ether investment by working on tooling we were in a very unique position in that regard at the moment cuz as developers you know you always want to be out there doing new things you don't want to be taking something that's already there and just they're working with the status quo and there is just so much stuff that needs to be built you know help grow this ecosystem and get more people involved because the bed of the tooling gets the more appealing if it comes to everyone else so it's it's a great time for developers to get into the space and and we are still at the ground floor you did not miss the train you did not miss the boat we are still in the very early days of all this all right so on the topic of open source what are the main challenges you what what are immense challenge challenges you face as an open source contributor and maintainer and how do you try to deal with those with those challenges stop so for me I think I think you know getting feedback from the users on the library and knowing what people are using it for that's very very hard is typically the main interactions you have with people when they've got problems or they're raising issues and then the add the other piece is just finding people to contribute so I think that's you know one of the best things is when these you know someone raises a pull request and they add in some new functionality that say you didn't even think about in a slightest it's the coolest thing when someone just donates their time and does that but it's hard to you know build up momentum around the projects and how people consistently come back again and again and again and and the just sudden knowing what people are doing with the library I think those are the two biggest challenges that I face anyway yeah I just I would second that like knowing how you're using it and what problems you're running into how did you start your environment so what environment did you start with was a truffle whatever and what kind of led to the lineage of your problems all of that stuff needs needs to be fully exposed opening lots of issues is so good and you know PRS yeah it is just the greatest feeling when someone random just shows up and helps you know improve your stuff and so yeah make lots of fantastic high-quality PRS and like kill it yeah I've had trouble with just ongoing support and that's just a problem with me spreading myself too thin across too many tools and too many libraries and same with the helping us with pull requests the users who answer questions and get er and respond to issues before I even get there are invaluable to me and and help so much but it's hard when there's when you're working on a lot of stuff and and there's a lot of support to be given it's not always our specialty we're not always great with interacting with people or not always great that the the documentation piece and things like that and and it's a there's a lot of different aspects to maintaining these things I would say that one of the challenges that that I see is well it's kind of what I said in my talk which is just that you know on the one hand when we release you know tools which are intended to be general-purpose and naturally we want to provide as good a support for them as you can but there's only 24 hours in the day and you know also if we gotta get you know I have to get my DAP augur to release so there's a you know there's some degree of tension between those two aims I think that something that's been very difficult in tooling specifically has been changing our minds it's been very difficult to change your to make a real change in your product after it's out there and after it's open-source and after it has users so our first tool was called dapple and it was something it was a labor of love I know Nick loved it for sure he was a biggest number-one fan for a while and it was something that was near and dear to our heart but for various reasons we decided to kind of pivot to just a different model you know we wanted to write it in bash instead of JavaScript and we wanted to take a different approach to it simplify it but that was difficult knowing that there were people already out there using it you know and there's and it was the same thing with our smart contracts too we we've created smart contracts and we've refined them and really thought about the many many times and changed them many times and this all of this stuff becomes magnified when you add in new people into the equation you know there's this whole it's difficult to kill your darlings when you're alone together in a room it's even more so when you've got a bunch of people who have started the repo and they're kind of expecting they have expectations about it so I think that making tough choices about your tools but for the right reasons has been something that we've found very challenging so the final question for the next 12 months what are you most excited about launching augur launching maker launching boardroom now becoming govern X I am really excited to get more people on board it to the Python ecosystem because we it has been a I don't know what the word I'm looking for here is but the Python ecosystem hasn't been amazing up until now and it hasn't been well supported and that is all changing the tools that we're making we have a team we have resources and that stuff is going to be worked on supported and we we want that ecosystem to grow and package management I want this next year to be the year that we get support for the spec and across the board and support and wallets and support and explorers for verification and that we actually see that take off I just want a second that the new pi-theorem is rad it's the also known as pi EVM yeah yeah it's it's very good it's very good definitely check it out yeah great work for me I think is just seeing where our theorems going in terms of like that the progress that's being made around scaling it and with initiatives like Klaus Moran's and the second chain coming along the metallic was talking about on the first day of the conference I think that's going to present all sorts of new challenges for the libraries in terms of through persons and in greater volumes and so that's really exciting time through so forth next wave morph it would be like testing and spitting down everything into several modules and yeah rating testing testing we like just to to say that we are proud now of what remix is it's real nice but one aspect that we need to improve is kind of the fact that you can use it in the browser it's very nice but if you have to deal with local files if you have to deal with continuous integration and all those 12 it's a bit more difficult so in the next year we will definitively improve that stuff yeah and to give a more thorough answer something that I'm really excited to see in the next 12 months is around formal verification one year ago I did not think that formal verification on aetherium would be as far ahead as it is today there's like measurable progress being made well yeah yeah and we're working on it at a pub there's other people working on in this space but it'll be I'll be very excited to see what happens in the next year on formal verification alright so we reach the end of the session if any of you want to talk to us about contributing to the tools or even creating your own tools please don't hesitate to to come and talk to us thank you [Applause] [Music]