Re:Ethereum from scratch – Part 1: Ping
by saurik on Thursday July 20, 2017 @06:12PM
(#14816729)
I view this more as "web apps should not be written in C++ due to security issues that we have long come to understand" than "web apps should be written in C++ due to performance issues we are guessing at"... like, do you believe that in a few years people will decide "no, strongly typed and proof assisted languages were overkill for contracts: it was actually better to code them in a language that has weirdly fluid rules and type semantics for reasons they did not quite grok in 2017"?
[ Parent
| on HN ]
Re:Ethereum from scratch – Part 1: Ping
by sillysaurus3 on Thursday July 20, 2017 @06:20PM
(#14816762)
This criticism doesn't apply to Ethereum. Solidity is compiled to a VM. You can write other languages that meet your criteria that still use Ethereum.
I know, and I am very excited for those languages to exist and be usable, and thereby have been tracking a couple such efforts; until then, this is about as useful as pointing out that website development is theoretically possible using a computer. The person did not state that it would always be the case that smart contracts are hard: only that right now, on Ethereum, they are hard, and the comment even used "gotten to the point where" (indicating this is a temporary state) and specifically blamed the "tools", which is all absolutely true and is born out not just in theory but in practice; it doesn't even disagree with your own statements that other different tools would be better. Why are you so defensive about this commentary?
Re:Ethereum from scratch – Part 1: Ping
by sillysaurus3 on Thursday July 20, 2017 @07:02PM
(#14816937)
I'm like a goalie. Defense is my game.
Actually, I didn't mean to come across as defensive. I just like to nerd out about tech.
Once you accept the inherent craziness of the proposal, and go "Ok, this is crazy. What now?" you end up concluding that the future is going to be very interesting. It'd be worth investing some amount (that you can afford to lose!) in ETH on the off-chance that it doesn't suffer a major disaster. There are quite a few interesting applications for this technology, and historically that's been a pretty solid bet.
The main thing to keep in mind at this point in time is that these contracts have very little tolerance for inefficiency, since inefficiency in this case costs money. Even solidity is very inefficient. Sure it would be great to write contracts in Haskell or Coq but can you insure O(1) or at most O(n) run time with little to no constant overhead? For example LLL (Low-Level Lisp-Like Language) produces 70% more efficient code than solidity [1] and thus it is the chosen language for the ENS (Ethereum Name Service) registry smart contract (who wouldn't want to pay 70 less for interacting with a contract?). But no doubt, better languages will come with time :)
[1] https://media.consensys.net/an-introduction-to-lll-for-ether...