DAML - a language purpose-built for the exchange of value
In Distributed Ledgers need more than traditional design patterns, Shaul asserted that because Distributed Ledger Technology (DLT) is a fundamentally new paradigm for operating applications that span multiple untrusted actors, programming languages used to build applications for more traditional environments are insufficient for writing smart contracts.
What, then, should a DLT contract language look like?
When it comes to DLT contract languages you must choose, but choose wisely
In our previous article Distributed ledgers need more than traditional application design patterns, Shaul pointed out that most DLT vendors deliberately choose to “pair their ledgers with programming languages that are general-purpose and familiar in an effort to appeal to the most widespread developer skills.” This approach is understandable, and reduces the learning curve, but features of those languages can cause unpleasant issues when used for writing DLT smart contracts. Tony Hoare refers to null pointers as his billion dollar mistake — in this post we’ll discuss some of the language features that have already led to multi-million dollar mistakes when used in a DLT setting, and suggest some properties that a contract language should exhibit to help avoid similar mistakes in the future.