<p>Marlowe... or its descendants/variations ;-)</p>
<p>I would like to emphasize the difference between Marlowe and all the other solutions and later on focus on Marlowe. I'll even allow myself to <strong>speculate</strong> a bit <strong>about</strong> its possible <strong>future</strong>:</p>
<ul>
<li><p>All the other languages compile down to a &quot;binary (lambda?) blob&quot; (Plutus Core) and that is how they end up on the chain.</p>
</li>
<li><p>Binary blobs of a Turing-complete program are generally hard to understand. It seems rather infeasible to build a generic tool for binary programs (considering issues like the halting problem etc.), which could analyze them and answer questions about what will happen in the future if I join the contract.</p>
</li>
<li><p>Marlowe doesn't compile to anything (by design!). It is interpreted on the chain, merely serialized and placed into the Datum..</p>
</li>
<li><p>Marlowe is limited and non Turing complete. You can analyze and discover a lot of properties of the contract statically.</p>
</li>
<li><p>Marlowe is severely limited on purpose. We are playing with peoples money here. It requires more thinking to design some contracts. Some contracts are just impossible in Marlowe (like &quot;open auction&quot;). But if you assume some &quot;sensible&quot; limits (do I have to support more than 1000 rounds in this auction? can I limit participants to some known group?) you can do a lot with it.</p>
</li>
<li><p>The Marlowe interpreter V1 will be a single identifier of a constant script (after its release, the Marlowe interpreter should be present on the chain as a reference script). So given an UTxO with a script hash and datum you are able to decode the whole picture of Marlowe interpreter state (there are some optional nuances about &quot;role token&quot; minting but we can ignore them in this discussion).</p>
</li>
<li><p>Marlowe is a pretty simple DSL and it can be produced from any programming language which supports JSON (json encoding is part of the official spec: <a href="https://github.com/input-output-hk/marlowe/releases/download/v3-rc2/specification-v3-rc2.pdf" rel="nofollow noreferrer">https://github.com/input-output-hk/marlowe/releases/download/v3-rc2/specification-v3-rc2.pdf</a> - page 62, Appendix E).</p>
</li>
<li><p>When you build a dapp (in any language!) you could on your backend or even frontend(!) have a template of a Marlowe contract which it can fill in with values (like addresses, amounts, timeouts etc.) dynamically.</p>
</li>
<li><p>Learning curve for Marlowe seems to be pretty low. Interestingly Marlowe pretty nicely integrates with the UTxO model. A step (&quot;user action&quot;) in a contract is usually translated to a transaction on the chain. A programmer can possibly transfer Marlowe knowledge between projects written in different languages, frameworks etc. (like we do with SQL or HTML/CSS knowledge).</p>
</li>
<li><p>Marlowe contract execution runtime which takes care of the deployment on the chain and monitors the chain is also in a pre-release phase. It exposes pretty simple REST API which can be naturally integrated into any project.</p>
</li>
</ul>
<p>What <strong>could</strong> it mean in practice?</p>
<ul>
<li><p>The audit's cost for a Marlowe-based solution should be much lower. Everyone has access to a set of static analysis tools for Marlowe. An audit may even be unnecessary in simpler scenarios.</p>
</li>
<li><p>The operational costs and business risks of Marlowe-based solution <strong>should</strong> be also lower - more developers can pick it up and learn etc.</p>
</li>
<li><p>Developers like to talk about performance and expresivness but I hope that in the domain of financial contracts they can see the value in the DSL which is limited but provides guarantees.</p>
</li>
<li><p>Because Marlowe is present on the chain as a 'source code' contracts could be visualized by wallets, explorers etc. In such a case user could just pick a dapp contract and possibly check the contract and answer a lot of questions himself before signing any tx.</p>
</li>
<li><p>Marlowe is not the only possible DSL which we could have. We can imagine other more expressive (with less guarantees? harder to visulaize?) or less expressive (easier to understand and visulaize) languages which we can build using this kind of interpreter pattern which gives the contract its transparent nature.</p>
</li>
</ul>

CC BY-SA 4.0
2023-05-19T10:28:30.100Z
2023-06-02T12:48:16.210Z
2023-06-02T12:48:16.210Z
paluh
<p><strong>PlutusTx inherits its qualities from Haskell, and thus has many of the same benefits/drawbacks:</strong></p>
<p><strong>Pros</strong>: auditability, maintainability, and upgradeability of code.</p>
<p><strong>Cons</strong>: developers' unfamiliarity with functional programming. High resource usage.</p>
<hr />
<p>PlutusTx is especially useful when safety and correctness are the #1 priority, such as in massive DeFi dApps or any other mission critical system.</p>
<p>On the other hand, PlutusTx is relatively resource-hungry (in terms of script execution units), which limits the size of deployable contracts. Although it may be possible to address some of these limitation through optimizations/changes to Plutus Core (i.e. <a href="https://github.com/cardano-foundation/CIPs/pull/309" rel="nofollow noreferrer">CIP-38</a>, <a href="https://github.com/cardano-foundation/CIPs/pull/455" rel="nofollow noreferrer">CIP-85</a> and others), newer languages like Aiken and Plu-ts offer a lighter-weight execution budget and greater accessibility to a broader set of developers.</p>
<p>Non-turing complete DSLs like Marlowe offer even greater developer accessibility via low-code or even no-code contract deployment.</p>
<p>TLDR; all of these are just tools in the toolbox. All (or most) of them will be future smart contract langugaes.</p>

CC BY-SA 4.0
2023-05-14T17:25:51.810Z
Aiken and PlutusTx both compile down to Plutus Core, which is the language understood and executed by a Cardano node. There is no inherent reason why PlutusTx should be more resource hungry than any other newer language. The question why it obviously is much more resource hungry can only be answered by the Cardano developer team.
Jey
CC BY-SA 4.0
2023-05-14T15:57:35.030Z
2023-05-14T15:57:35.030Z
zhekson
<p>As we might know well-known approaches for writing smart contracts on Cardano are using Plutus Tx or Marlowe based on specific requirements. However, according to the growth of the Cardano community, many new choices for writing smart contracts appear. Could Plutus Tx be a good choice in the future?</p>
<p>List of possible tools:</p>
<ol>
<li>Plutus Tx</li>
<li><a href="https://play.marlowe-finance.io/#/" rel="nofollow noreferrer">Marlowe</a></li>
<li><a href="https://github.com/OpShin/opshin" rel="nofollow noreferrer">OsPhin</a> - Python</li>
<li><a href="https://github.com/HarmonicLabs/plu-ts" rel="nofollow noreferrer">Plu-ts</a> - Typescript</li>
<li><a href="https://github.com/aiken-lang/aiken" rel="nofollow noreferrer">Aiken</a>- new language (Rust compiler)</li>
<li><a href="https://github.com/Hyperion-BT/Helios" rel="nofollow noreferrer">Helios</a> - new language (Javascript compiler)</li>
<li>etc</li>
</ol>

CC BY-SA 4.0
2023-04-19T11:08:56.683Z
Do you mean PlutusTx for point 1?
james
CC BY-SA 4.0
2023-04-19T11:29:04.107Z
Yes, I've updated it. Thank you
manhdt
<plutus><smart-contract><marlowe><helios>
Which would be the future language for writing smart-contract?
# Which would be the future language for writing smart-contract?

(Asked by: username_0 on 2023-04-19)

As we might know well-known approaches for writing smart contracts on Cardano are using Plutus Tx or Marlowe based on specific requirements. However, according to the growth of the Cardano community, many new choices for writing smart contracts appear. Could Plutus Tx be a good choice in the future?

List of possible tools:

1. Plutus Tx
2. [Marlowe](https://play.marlowe-finance.io/#/)
3. [OsPhin](https://github.com/OpShin/opshin) - Python
4. [Plu-ts](https://github.com/HarmonicLabs/plu-ts) - Typescript
5. [Aiken](https://github.com/aiken-lang/aiken)- new language (Rust compiler)
6. [Helios](https://github.com/Hyperion-BT/Helios) - new language (Javascript compiler)
7. etc

**Tags:** plutus, smart-contract, marlowe, helios
> **Comments:**
> **username_1**: Do you mean PlutusTx for point 1?  
> **username_0**: Yes, I've updated it. Thank you  

---

## 2 answers

### Answer by username_3 on 2023-05-14. Score: 3

**PlutusTx inherits its qualities from Haskell, and thus has many of the same benefits/drawbacks:**

**Pros**: auditability, maintainability, and upgradeability of code.

**Cons**: developers' unfamiliarity with functional programming. High resource usage.

---

PlutusTx is especially useful when safety and correctness are the #1 priority, such as in massive DeFi dApps or any other mission critical system.

On the other hand, PlutusTx is relatively resource-hungry (in terms of script execution units), which limits the size of deployable contracts. Although it may be possible to address some of these limitation through optimizations/changes to Plutus Core (i.e. [CIP-38](https://github.com/cardano-foundation/CIPs/pull/309), [CIP-85](https://github.com/cardano-foundation/CIPs/pull/455) and others), newer languages like Aiken and Plu-ts offer a lighter-weight execution budget and greater accessibility to a broader set of developers.

Non-turing complete DSLs like Marlowe offer even greater developer accessibility via low-code or even no-code contract deployment.

TLDR; all of these are just tools in the toolbox. All (or most) of them will be future smart contract langugaes.

> **Comments:**
> **username_4**: Aiken and PlutusTx both compile down to Plutus Core, which is the language understood and executed by a Cardano node. There is no inherent reason why PlutusTx should be more resource hungry than any other newer language. The question why it obviously is much more resource hungry can only be answered by the Cardano developer team.  

---

### Answer by username_2 on 2023-05-19. Score: 1

Marlowe... or its descendants/variations ;-)

I would like to emphasize the difference between Marlowe and all the other solutions and later on focus on Marlowe. I'll even allow myself to **speculate** a bit **about** its possible **future**:

* All the other languages compile down to a "binary (lambda?) blob" (Plutus Core) and that is how they end up on the chain.
* Binary blobs of a Turing-complete program are generally hard to understand. It seems rather infeasible to build a generic tool for binary programs (considering issues like the halting problem etc.), which could analyze them and answer questions about what will happen in the future if I join the contract.
* Marlowe doesn't compile to anything (by design!). It is interpreted on the chain, merely serialized and placed into the Datum..
* Marlowe is limited and non Turing complete. You can analyze and discover a lot of properties of the contract statically.
* Marlowe is severely limited on purpose. We are playing with peoples money here. It requires more thinking to design some contracts. Some contracts are just impossible in Marlowe (like "open auction"). But if you assume some "sensible" limits (do I have to support more than 1000 rounds in this auction? can I limit participants to some known group?) you can do a lot with it.
* The Marlowe interpreter V1 will be a single identifier of a constant script (after its release, the Marlowe interpreter should be present on the chain as a reference script). So given an UTxO with a script hash and datum you are able to decode the whole picture of Marlowe interpreter state (there are some optional nuances about "role token" minting but we can ignore them in this discussion).
* Marlowe is a pretty simple DSL and it can be produced from any programming language which supports JSON (json encoding is part of the official spec: <https://github.com/input-output-hk/marlowe/releases/download/v3-rc2/specification-v3-rc2.pdf> - page 62, Appendix E).
* When you build a dapp (in any language!) you could on your backend or even frontend(!) have a template of a Marlowe contract which it can fill in with values (like addresses, amounts, timeouts etc.) dynamically.
* Learning curve for Marlowe seems to be pretty low. Interestingly Marlowe pretty nicely integrates with the UTxO model. A step ("user action") in a contract is usually translated to a transaction on the chain. A programmer can possibly transfer Marlowe knowledge between projects written in different languages, frameworks etc. (like we do with SQL or HTML/CSS knowledge).
* Marlowe contract execution runtime which takes care of the deployment on the chain and monitors the chain is also in a pre-release phase. It exposes pretty simple REST API which can be naturally integrated into any project.

What **could** it mean in practice?

* The audit's cost for a Marlowe-based solution should be much lower. Everyone has access to a set of static analysis tools for Marlowe. An audit may even be unnecessary in simpler scenarios.
* The operational costs and business risks of Marlowe-based solution **should** be also lower - more developers can pick it up and learn etc.
* Developers like to talk about performance and expresivness but I hope that in the domain of financial contracts they can see the value in the DSL which is limited but provides guarantees.
* Because Marlowe is present on the chain as a 'source code' contracts could be visualized by wallets, explorers etc. In such a case user could just pick a dapp contract and possibly check the contract and answer a lot of questions himself before signing any tx.
* Marlowe is not the only possible DSL which we could have. We can imagine other more expressive (with less guarantees? harder to visulaize?) or less expressive (easier to understand and visulaize) languages which we can build using this kind of interpreter pattern which gives the contract its transparent nature.


---

