LLL: A Viable Alternative to Solidity?

    Well-Known Member Staff Member
    Likes Received:
    Trophy Points:
    May 14, 2018 at 10:37
    Before Solidity, Ethereum smart contract developers used LLL (short for Lisp-Like Language). Being a somewhat ‘low-level-language’, LLL is often compared to Assembly language. However, it’s simple and minimalistic structure makes it quite readable when formatted properly (and its much simpler than common Lisp). Instead of JavaScript-like braces, LLL developers simply use parentheses for parsing (as Lisp does). And like Python, LLL developers employ indentation to indicate code blocks. So anyone viewing LLL will notice its very concise and straightforward, making it easy for developers to code with..

    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 that many developers appreciate.
    • Likewise, 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 from LLL being a low-level language. However, the latter ensures that LLL does not incorporate stack management and jump management options either (a welcome relief to many developers!). Nonetheless, proponents assert that LLL “provides a different perspective and programming discipline when compared to the ubiquitous Solidity language.” (Github: LLL Introduction )

    So Why Solidity?

    Solidity retains serious security issues and is not easily accessible to the casual developer (being notably difficult to comprehend at times). For instance, its “stored procedures are not something that the average developer writes on a regular basis”. However, Solidity provides “the best interoperability with the Javascript APIs” (reddit). This alone is the primary reason that it is used over LLL and Serpent (a smart contract language that actually compiles down to LLL).

    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 gets the most support.

    Still, LLL should get a second look by 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 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 bright future for any develop interested in DApps.

    The Github Repository for LLL;
    LLL Compiler Documentation

    For detailed feedback- please email [email protected]

    The post LLL: A Viable Alternative to Solidity? appeared first on XTRABYTES Today.

    Continue reading...