To understand LIGO’s design choices, it’s important to get its philosophy. There are two main concerns that we have in mind when building LIGO.
Once a smart-contract is deployed, it will likely be impossible to change it. You must get it right on the first try, and LIGO should help as much as possible. There are multiple ways to make LIGO a safer language for smart-contracts.
Automated Testing is the process through which a program will run some other program, and check that this other program behaves correctly. There already is a testing library for LIGO programs written in OCaml that is used to test LIGO itself. Making it accessible to users will greatly improve safety. A way to do so would be to make it accessible from within LIGO.
Static analysis is the process of having a program analyze another one. For instance, type systems are a kind of static analysis through which it is possible to find lots of bugs. There is already a fairly simple type system in LIGO, and we plan to make it much stronger.
Writing less code gives you less room to introduce errors and that's why LIGO encourages writing lean rather than chunky smart-contracts.
Having an ergonomic product is crucial on multiple levels: Making features easily accessible ensures they’ll actually get used. Not wasting users time on idiosyncrasies frees more time for making contracts safer or building apps. Keeping users in a Flow state makes it possible to introduce more complex features in the language. There are multiple ways to improve ergonomics.
LIGO should contain as few surprises as possible. This is usually known as the principle of least surprise.
It is packaged in a Docker container, so that no particular installation instructions are required.
Without editor support, a lot of manipulations are very cumbersome. Checking for errors, testing, examining code, refactoring code, etc. This is why there is ongoing work on editor support, starting with highlighting and code-folding.
Docs include documentation of the languages, tutorials, as well as examples and design patterns. We’re a long way from there. But having extensive docs is part of our goals.