Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this community
Solidity is a new language designed specially for writing Ethereum smart-contracts. As compared with Serpent, which is an extension to Python semantics, Solidity is completely new and borrows semantics from other languages to be JavaScript-like.
What was the motivation for designing the language and features it should have and were any specific tradeoffs made during the process of building it?
There's some explanation in the original design proposal here: https://t.co/An1ZpRSu7O .
Basically, it was meant to use some OOP features to provide a convenient abstraction for contracts. Objects' data could be arbitrarily complex through its mapping mechanism. The original design included the ability to specify (and therefore optimise) that mapping. For objects' functions, I leveraged the then-new Ethereum contract ABI specification to synthesise something familiar to OOP practitioners. The introduction of the constant function marker was also quite nice, since it allowed an optimised way of inspecting object state with Solidity logic.
It was meant to be a sophisticated tool for developing contracts that could ultimately give both developers and users good information on what the code did. To help this along, I devised NatSpec, a contract-friendly documentation format, and made that a first-class citizen in Solidity. I also proposed a formal proofing language subset (not yet implemented) in order to maximise the kinds of correctness guarantees that could be made.
I introduced events as a first class citizen into the Solidity language in order to provide a nice abstraction for LOGs similar in form to function calls. Inspiration for that came from the Qt meta-object system's "signals".
One later feature that Christian R. and I figured out together was function modifiers; that allows attributes placed as part of a function signature to make some modifications to the apparent function body. Being a very declarative means of expression, it's an idiom that falls nicely into the contract-oriented programming space.
