plutus VS Formality

Plutus-related issues in Plutus repo https://github.com/input-output-hk/plutus/issues Cardano node-related issues in the Cardano node repo https://github.com/input-output-hk/cardano-node

Plutus (Haskell) is a statically typed programming language wired for writing reliable smart contracts on the Cardano blockchain. It is also a functional programming language, which means programs are composed as sets of mathematical functions for execution.

* https://github.com/input-output-hk/plutus

There's quite a few recent Isabelle repos such as https://github.com/input-output-hk/high-assurance-legacy

I haven't worked there for a year or so and don't remember specifics like KLOCs, just that they're dotted around internal and public repos :)

PR for Improved Rational for on-chain size was merged into Plutus: https://github.com/input-output-hk/plutus/commit/6d8d25d1e84b2a4278da1036aab23da4161b8df8

Cardano also suffers from the issue of the size of Plutus script being too big. One script can eat up to 20% of block which renders the overall efficiency even worse.

They're working on script libraries where you can reference a script in another UTXO rather than having to reinclude it every time. This is mentioned in some videos (I think in November's mid month update and Cardano 360), if you don't have time to watch those it's mentioned in michaelpj's comment here along with some other optimisations they're working on https://github.com/input-output-hk/plutus/issues/4174

There is a discussion on GitHub about this. The second solution in MPJs reply is what you are suggesting.

About to say that lol. Here are more info.https://plutus-apps.readthedocs.io/en/latest/index.htmlhttps://github.com/input-output-hk/plutushttps://docs.cardano.org/plutus/learn-about-plutus

Also, my current work is using Kind as a foundation, the purpose of this language is exactly what you have asked for, give a check on https://github.com/uwu-tech/Kind.

Kind has a "how I learned to stop worrying and love the `Type:Type`" vibe. That doesn't make it invalid as a proof language. It just inverts the priority: instead of consistency being the default and expressivity being opt-in (as in Agda, with the `type-in-type` pragma), it is expressive by default, and consistency is an opt-in. I strongly believe that is the right way. We plan to add opt-in termination (thus consistency) checkers, it is just not an immediate priority, but the language is completely ready for that. About `Type in Type` specifically, keep in mind that there are consistent, interesting type theories that feature `Type in Type`. So it isn't problematic in itself, and removing it seems wrong.

About erasure, you can flag an argument as computationally irrelevant by writing `` instead of `(x: A)`. So, for example, in the [Vector/concat.kind](https://github.com/uwu-tech/Kind/blob/master/base/Vector/con...) file, `A`, `n` and `m` are erased. As such, the length of the vector doesn't affect the runtime. As a good practice, you may also write `f` instead of `f(x)` syntax for erased arguments, but that is optional.

> TL;DR -- I think the language looks nice, and the compile to JS (from what I read of the Formcore source) looks to be well done. Also, the docs that are present are well presented in a non-academic way that I find pretty readable.

Thanks for the kind words. We put a lot of effort on the compilers and, while there is still a lot to improve, I'm confident they're ahead of all the other languages, by far.

Kind is a functional, general-purpose programming language featuring theorems and proofs. It has the smallest core, a pretty solid JavaScript and Scheme compiler (seriously, check how clean is the generated kind.js), and a syntax that is a middle ground between Haskell and TypeScript, in an attempt to make it more accessible.

I'm writing CONTRIBUTE.md right now.