[malux85]

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

[quickthrower2]

There was a semi-joke post on HN a while back where someone created a 'pyramid' lispy language using Racket, which complied to solidity.

But in seriousness, a Haskell -> solidity compiler, might make it bearable.

[remcob]

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.

Recently I've been doing some combined Solidity/EVM-assembly that I wrote about [here](https://medium.com/wicketh/mathemagic-chinese-remainder-theo...). I'll post more this month doing some advanced tricks in Solidity/EVM.

[wrinkl3]

This is a genuinely great insight. What would you say are the biggest features absent from the language right now?

[UncleMeat]

Even evm has gotchas and problems. It isn't just solidity that has design flaws.

[mbrock]

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.

https://publications.lib.chalmers.se/records/fulltext/234939...

But I do think it's very interesting to think of Haskell as a powerful metalanguage for defining smart contracts that then get compiled to EVM.

Other examples of Haskell as a DSL environment for generating more restricted programs:

https://hackage.haskell.org/package/accelerate

http://ku-fpg.github.io/software/kansas-lava/

http://www.clash-lang.org/

Quote from the Kansas Lava site:

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:

https://github.com/dapphub/ds-weth/blob/master/src/weth4.hs

Of course we want to take this further and find some more abstractions for cleanly expressing actual smart contract patterns...

[jjn2009]

by solidity do you mean EVM?

[quickthrower2]

probably. pardon my ignorance.

[stevehawk]

> early html development was poor,

what you got against <blink>?

[tehlike]

<marquee> was better.

[50CNT]

Can't believe you're siding with IE over Netscape.

[tehlike]

Couple years(?) back, i stumbled upon this blog post about the origin of <blink> http://www.montulli.org/theoriginofthe%3Cblink%3Etag

[nikkwong]

Could you touch on what you find are the short comings of solidity?

[thisisit]

> But! It’s the 1.0 of crypto.

What will(is) the crypto 2.0 ?

[sAbakumoff]

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.

[fourstar]

EOS.

[patrickaljord]

What do you think of viper?

[yekm]

What do you think about other blockchain related projects, like exonum or eos?