LLL’s Many Advantages
While writing code in LLL is fairly easy, LLL avails developers with other strengths as well:
- Unlike Solidity, LLL developers are able to directly access memory and storage. This means that LLL developers can effectively arrange contract data as they see fit.
- LLL also employs ALL Ethereum Virtual Machine (EVM) opcodes (operational codes like ADDRESS, STACK, ORIGIN, PUSH1)…but without the high-level entanglement found in Solidity. Its this power and economy of code that many developers appreciate.
- Again- brevity. Smart contracts written in LLL compile to smaIler binaries than Solidity contracts- up to 70% smaller (consensys.net).
- While critics view LLL as little more than assembly code with Lisp syntax, it “provides control structures (for, when, if, etc.) that are difficult and confusing to do in assembler. It also provides other convenient abstractions such a macros, and has the ability to include other source files as well” (syrinx.net).
These benefits accrue to LLL despite it being a low-level language. While LLL does not allow for stack management and jump management as Solidity does, many developers find that a welcome relief. Indeed, LLL continues to gain adherents simply because its Not Solidity. These fans appreciate the “different perspective and programming discipline (LLL provides) when compared to the ubiquitous Solidity language” (Github: LLL Introduction).
So Why Solidity?
Not Entirely A Language Issue
Since few developers are keenly aware that Serpent (now revised as Viper) and LLL exist, many are choking down Solidity as the mainstay smart-contract language. It’s simply the best documented smart contract language out there (although hardly in an impressive way). And it also gets the most support.
Still, LLL should get a second look from smart contract developers. Several proponents are seeking to resuscitate its use (see Daniel Ellison’s article “The Rise of A Forgotten Language”). Other languages should be considered by smart contract developers as well. As one Reddit commentator noted “The only requirement though is building a compiler that can translate the language to EVM bytecode. Anyone could make smart contracts in Java, Python, C, etc. as long as the appropriate compilers existed.”
If so, perhaps developers need a platform that is much more versatile. One that doesn’t require jumping through so many hoops in order to translate language to EVM bytecode. It’s possible (even likely) that a code-agnostic platform like XTRABYTES platform may serve that role in the near future. It certainly appears to offer a brighter future for any developer interested in creating new and exciting DApps in the language of their choice.
For detailed feedback- please email [email protected]