[drcode]

To be fair, ethereum has bytecode at its base- almost certainly someone will wrote a more declarative language on top of it now to help minimize the chance that unexpected calling trees can lead to unexpected behavior.

Also, the existing solidity language is pretty well designed, it's just a hard problem and an even better design may be needed.

[naasking]

> To be fair, ethereum has bytecode at its base- almost certainly someone will wrote a more declarative language on top of it now to help minimize the chance that unexpected calling trees can lead to unexpected behavior.

The mismatch between executable code and high-level language is a known attack vector called the "full abstraction" problem. This has already been used to subvert the CLR and the JVM. If your bytecode is not inherently secure, and you permit executing arbitrary bytecode, then any language running on top that builds more sophisticated invariants that aren't enforceable via the bytecode are very likely vulnerable.

[Animats]

Almost certainly someone will wrote a more declarative language on top of it

Papering over the mold seldom works. It makes things easier, not more reliable. See C++ templates.

[Animats]

Note that putting a language on top of the existing language won't prevent VM stack overflows of the type used in the attack. It's more likely to hide them.

[drcode]

A better example is Haskell, which usually compiles down to a low level C dialect.

[amaks]

Any language can compile to the low level C dialect.