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.
The role of language in DLT-based financial markets
Modern society depends on the secure transfer of value in nearly every aspect of life — from transfers of stock, bonds, or cash on the books of financial markets to the consumption of digital content for a fee. Despite the pervasiveness of financial transactions and decades of operational experience executing them, two major problems remain unsolved:
Executing transactions is still complex, opaque, expensive, and full of operational risk.
Despite blazingly fast innovation in other areas of software development, innovation in the world of cross-enterprise workflows is painfully slow.