I recently got pretty pumped about exploring developing for the Ethereum network and spent an entire weekend reading everything I could about the protocol, the development ecosystem, language and anything else I could find - blog posts, tutorials, experiences from other developers.
I came away with my initial enthusiasm completely dashed. I can't for the life of me imagine why any sane developer would ever want to work within the constraints of Ethereum. It just doesn't seem to me anywhere near ready for any kind of serious development, or even trivial development for that matter.
I'd love to hear rebuttals to this. Is anyone out there doing anything interesting with this platform?
I’m a pretty experienced solidly / ethereum developer, and a developer with 13 years experience in vast array of systems and languages (from embedded C on ppc to high performance c++ and now deep learning and scientific computing in python). I completely agree with you, that there’s some very odd language choices in solidity, seemingly rookie mistakes, and the tooling is very poor. But! It’s the 1.0 of crypto. Early C stuff was poor, early html development was poor, early OpenGL development was poor, it’s just new.
I see it as a lot of room for opportunity, but I could also see how it could be frustrating to some more senior people - but I have found part of growing old and seeing things constantly get re-invented but slightly different are windows of opportunity - so I get excited
Solidity is a complex moving target with limitations such as max 16 local variables, missing optimizations and only partial support for dynamic allocation.
You might want to compile directly to EVM instead of through Solidity. The EVM is very simple, as far as virtual machines go. It's fully documented in [the yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf) and only changes with hardforks (and then only incrementally in a backwards compatible way).
Smart contract development feels like embedded systems development. Every instruction has a significant cost associated to it. There are different memory spaces like a Harvard architecture (code, memory, storage, input, output, other peoples code). Like embedded systems, you need to be absolutely sure your code is correct before you deploy, as updates are impossible and a lot of economic value depends on correctness.
But contrary to embedded systems it has 256 bit registers, 256 bit address space and SHA3 as a cheap instruction. This means that if you pick a 'random' hash, you can safely assume it's free! Hashtables in Solidity are implemented like this.
Suboptimal smart contracts directly incur unnecessary transaction costs for users, and it's hard to imagine that Haskell as a source language would translate to efficient EVM bytecode.
For one, do you really want to have a lazy evaluation runtime compiled into your multisig? Now do you want to prove the correctness of that runtime? ...
I don't think Haskell is anywhere near a good source language for Ethereum smart contracts, if you think of it as "compiling Haskell".
There was a master's thesis about compiling Idris to EVM, and it also shows that the performance problems are difficult indeed even without laziness.
Kansas Lava is a Domain Specific Language (DSL) for expressing hardware-oriented descriptions of computations, and is hosted inside the language Haskell. Kansas Lava programs are descriptions of specific hardware entities, the connections between them, and other computational abstractions that can compile down to these entities. Large circuits have be successfully expressed using Kansas Lava, and Haskell’s powerful abstraction mechanisms, as well as generic generative techniques, can be applied to good effect to provide descriptions of highly efficient circuits.
That's an approach I think is much more appropriate for the strengths and weaknesses of Haskell!
As it happens, we've started very modestly at using Haskell like this. At the moment we only have a simple monadic assembler that lets you write EVM code. See this example:
state-regulated crypto currencies. It might sound strange, but Russia might be the first country that starts this practice. I wouldn't be surprised if Mr. Putin will make it part of his play book for the upcoming presidential elections. When it might be China. Once USA will throw Mr. Trump out of the WH and the sane person will rule the country, they will want to regulate crypto as well.
I believe a huge barrier to entry is the lack of accurate, concise documentation.
I did my fair share of solidity development myself and it was hard for me to find references on simple basic development on the platform. Diff ways to setup, diff sandboxes, no proper introduction of the tools, etc.
I had the exact same experience, joined a project which was relying upon Ethereum. Spent several days learning everything about it and messing with the technology. Every moment the interest slowly waned as frustration upon frustration added up into a realization that this tech is nowhere near ready to base huge important projects off of it.
Here were mine
Here were a few of mine, I’ve tried to get into ethereum a couple times
- installing mist and getting it to sync is very difficult and time consuming
- connecting to a testnet and getting ether on the testnet is also very difficult
- most ‘cool’ dapp ideas rely on oracles to publish data about the real world into the block chain. When you dive into it you realize that such an Oracle would be very very expensive to run for even trivial usecases.
> most ‘cool’ dapp ideas rely on oracles to publish data about the real world into the block chain. When you dive into it you realize that such an Oracle would be very very expensive to run for even trivial usecases.
For example, if the problem domain is football games and gambling, well, scraping the results of those games from existing apis isn't too hard nor expensive.
If it's based on real-world stuff with no existing consistent API (e.g. you want a app based on housing), you'll either need to build that API, find a company to research and enter the data, etc.
There are implementations like Chainlink running decentralized oracles. At the end of the day, the data-source is still the bottleneck but they try to discourage bad actors through e.g. reputation mechanisms.
An Oracle is just a program that movies data onto the blockchain for dapps to use.
The data is an input to a transaction that eventually results in the EVM storing that data into a contracts (dapps) memory (which you pay per byte) that can then be exposed to other dapps.
So both instructions and memory uses something called gas. Right now 1 gas = 0.00000002 eth.
Now a MUL costs 5 gas and a ADD costs 3 for example. So you have to pay for contract complexity.
Now memory costs are not linear. The current gas cost equation for memory is Gmem * a * (a^2/512) where Gmem is a constant that is currently 3 and 'a' is the number of 255bit words (ints) you are storing.
This is for EVM internal memory that can later be accessed by the smart contract or other contracts. There is a way for contracts to output data that can be read out-of-band called logs but that is for getting data out of the EVM, not in.
You have to conceptualise ethereum as a market communication bus to exchange business information between autonomously acting market partners. Nothing more nothing less.
Smart contracts encapsulate market logic, i. e. the stuff where market partners have a need to verify that the information (or value) shared was/is processed exactly as specified.
The key insight is to limit your utilisation of smart contracts to this type of application. You want to keep your smart contract super simple and focused on doing only one thing. Also note that marktet logic is almost always just a tiny fraction of the overall business logic of whatever you are building. So there will always be this other place where you develop the rest of your app with more traditional means (e. g. Javascript)
To integrate the blockchain powered market communication bit into your app, you simply wrap your deployed smart contracts into a software wallet such as ethters.js. This makes the solidity methods available in you application as simple js functions via dot notation for example.
you can just `require` the business object in you app and have access to 30 or so smart contracts that fire into a PoA blockchain network called Fury. Its actually quite simple. Take a look at the tests in the github repository. You can even trigger smart contract factories to mint your own preconfigured contracts if need be.
Here is an other example. A subset of the same smart-contracts but implemented withing a command line tool:
What you end up with then is a rather traditional app that 'composes' smart contracts to read and write stuff into/out of a blockhain network where appropriate.
Ethereum is limited. If you ran into limits with solidity then you ran up against the limits of Blockchain tech as we enter 2018. Use those limits as programming puzzles and go create something great. I find the limitations make me more creative. Solidity has some funkyness and that will get resolved, but there is still a ton you can do with it.
Glad I'm not insane, spent a long haul flight digging into Solidity docs and truffle and it seemed like a minefield of trouble to build crippled applications.
I've only tried some small things with it, but ever understanding what it was trying to do two years ago was a major challenge. Not Urbit-level esoteric, but in the same realm.
At least now it's more or less coherent with some good intros and good tutorials.
One thing I do like is having a meaningful incentive to be efficient. Kinda like my earliest days fiddling with assembler as a kid.
Jade/Pug comes to mind. Pug (the HTML templating language) was originally called Jade.
Jade is already a programming language (well, whole environment) made by Jade Software in New Zealand. They literally took the name of another programming language.
You can use web3.py (https://github.com/ethereum/web3.py) to interact with Solidity contracts using Python. I'm looking into using it instead of truffle/web3.js so I can stick with a Python stack.
* dealing with testrpc and tests is much easier in embark
* better documented and more configurable
* embark CLI more powerful and has help, while truffle almost doesn’t
* truffle has so many trivial bugs that are unresolved for months, usually no even word in reply from developers. Embark developers seem to fix bugs faster.
* integration with IPFS, Whisper OOB.
* probably forgot something else important. Overall experience is so much better with Embark.
I also tried to develop with Truffle but after a few hours I decided to avoid it and really start learning all the internals without a framework. To this day I haven't had the need to use Truffle at all to develop the majority of my projects.
I came away with my initial enthusiasm completely dashed. I can't for the life of me imagine why any sane developer would ever want to work within the constraints of Ethereum. It just doesn't seem to me anywhere near ready for any kind of serious development, or even trivial development for that matter.
I'd love to hear rebuttals to this. Is anyone out there doing anything interesting with this platform?