21

Solidity can be considered a "higher level" language than Serpent. Are there any "low level" features in Serpent or that could be implemented in Serpent, that are either impossible or infeasible to do with Solidity?

If there are, an order from what's impossible, to what's infeasible or unlikely to be implemented in Solidity, would help us determine if one must be used over the other.

13

Answer

I don't think there is a "limitation" to Solidity being able to implement low level features/accesses, such as the types of things Serpent can do. However, the two languages may have different priorities. Serpent is likely focused on lower level features compared to the flagship high-level language Solidity.

Ethereum high-level languages in order by closeness you can get to directly access the EVM:

  1. LLL (lowest level, basically 1 step above EVM byte code)
  2. Serpent (super-set of LLL)
  3. Solidity (compiles down directly to EVM byte code)

Details

Serpent has direct access to EVM opcodes (it is a superset of the LLL high-level language), but it also has a bunch of high-level features as well. The downside to Serpent is that the compiler is more complex and so theoretically might contain more bugs.

It can be argued that Solidity is more prone to stack-depth related problems:

Vitalik Buterin wrote this Reddit comment:

Solidity compiles all variables into values on the stack, and DUPN methods in Ethereum only let you fetch the 2-16th value from the stack at any one time. The actual stack depth is 1024. Serpent variables compile into memory accesses, so you don't have that problem in serpent; to get around it in solidity I'd recommend you try to pack things into structs more.

Being the flagship language, Solidity has been focused on different priorities than Serpent. Solidity has been less focused on adding low level features in favor of higher level features, but I don't think it is impossible to add more low level features to Solidity. In fact, there is a story on the Solidity development roadmap to add inline ASM into Solidity, which would allow lower level access to the EVM.

  • 2
    To minimize confusion, perhaps just use one of the terms ASM or EVM byte code? Readers may not understand they are the same concept. (IMO latter is clearer and used more from what I've seen) – eth Feb 9 '16 at 5:28
  • I agree. Edited :) – Hudson Jameson Feb 9 '16 at 19:49
1

This is not exactly a comparison of the two languages, but is relevant for someone looking to consider one over another.

An audit has founded critical bugs in Serpent, with the auditors calling Serpent project "low quality" and "flawed."

Vitalik, who wrote Serpent, said this in a tweet: "PSA: I now consider Serpent outdated tech; not nearly enough safety protections by current standards."

It also looks like Vitalik will not continue to develop Serpent, with his focus on Viper, which he also tweeted is not ready until after an external audit.

Zeppelin report suggests Solidity is the best available answer today, since more developers are working on it and it is the flagship language. Having said this, they have yet to do the same audit for Solidity.

-1

The major difference is a syntax. Serpent is more python like while Solidity is javascript cpp like

But Solidity is also better developed and has nice feature as templates.

You will find much more examples of solidity code online.

  • 2
    This is the start of a good answer, but I agree with OP that the best answer will probably include a list that scales from feasible to infeasible. Would you like to the solidity code and then create / start a list? – New Alexandria Jan 20 '16 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.