A thought on the Application Process

[mariari]

In this post i want to explore a concept I have only begun to think of since yesterday. While discussing the Kudos Application with @cdetroye, an interesting thought went through our heads:

“What if we just used Juvix for Resource Logics?”

In the current phase of application development we are at an impasse, transactions, resource logics, and transaction functions are all written in Juvix, and fetching data from metamask and the controller are in Elixir. Further the logic stringing together the various compiler passes and munging data is best done in Elixir (our tutorials say to use a horrid make file, but we disagree). What this ends up looking like is a few dozen lines of elixir holding together the main moving mechanics of applications, with the Juvix code being the payload we deliver that does some constraint checking.

We currently have plans that will minimize the amount of Elixir code to the amount of “in system code” [read juvix] (the final touchups on V0.2 will allow scrying for certain data online, v0.3 and v0.4 include changes that could allow our local environment to ask for signatures on identities (metamask), etc etc.).

However as we move more and more of this code out of Elixir and into Juvix we will run into some issues some of which were outlined in a previous post I’ve made here:

On an Implementation for Anoma Level

The Current Issue When designing and implementation a programming language for a new operating system, it becomes hard to separate where the language begins and where the OS begins. Even in an operating system like Unix with C this is the case, we can distinguish C, however our interface in interacting with Unix is primarily through sys calls in C and bash to script it together. The system is suboptimal but you can tell that Unix works as fundamentally a C machine. Operating systems like Xerox’s…

The post is more general and a bit higher level, the gist being that Juvix was designed to run in short applications stringent purely functional applications and by kludging it into something that it isn’t it will come up short where we need it. For the purposes of this post this comes through in the following questions:

1. How would we encode events being sent to processes… How do we even represent processes for that matter?
2. How would juvix code handle data that it does not expect? Messages will be sent across the network and AppData has heterogenous data, and although we can model the data coming in as ADT’s, from Juvix’s perspective this would need to be deseralized into the ADT (it’s not transparent) instead of just being able to natively see what the data ought to be (this is sometimes known as running the type checker at run time or encoding predicates and data formats to the terms given to you in terms of normal term usage).
3. How do we deal with serialization? Noun data structures aren’t reified into Juvix (IIRC), meaning that we could derive structures but some works needs to be done here first.

Thus another route that we could go that I have not considered before is:

“What if we just used Juvix for Resource Logics?”

This is interesting as although this goes away from our intended end-state (I.E. there is no Elixir, only a language that is destined to work at the anoma level!), however it does gives us some interesting benefits some of which we actually do today!

1. We can use Juvix as it was intended without many extensions. Juvix for short lived programs where the data is known upfront works well enough on this end. The only extension point is potentially we may want subtyping to help make resource logics more generic (Object systems for applications: step-by-step and A Proposal For a Flexibly Shielded RM Implementation may be relevant readings for the direction we will want to go with here).
2. We can use Elixir to peek into the system and orchestrate things. Elixir is fairly high level and has a pretty decent API for using the system. It is not surprising we currently use it to stitch together the development process.
3. We could build around the Elixir development flow for the time being, reducing the number of steps the user has to do, as to make up for the lack of a system, Elixir can step in and fill those in while utilizing the system. We already do this in the Shielded case as @Lukasz wrote logic inside of Elixir that effectively ties together the shielded RM with Elixir.
   1. We can use this to give live example data to juvix programs so we can call them live. I.E. we can utilize the fact that Juvix compiles to nock code, and create example conditions in which things live or fail and give quick feedback to how a transaction may go. This is currently harder as this requires Juvix being hookedup to Anoma typically I.E. not something we can do until we have a Juvix REPL that can integrate with the local domain.
   2. Push Key applications.
   3. More Inspectable transactions before shielding (for debugging we can look at the structures in an Elixir inspector and learn a lot more).
   4. Utilize more mature tooling.
4. We can have a mostly unified Development experience, by doing this, we can compose transactions, listen to events on the system about one’s resources and deal with metamask integration seemlessly. Meaning that 90+% of the application will be elixir with a bit of Juvix for the more constrained validity checks.

The main drawbacks are as follows:

1. This gets away from having development be in system. Instead we are doing it outside of the system.
2. We have to consider how “transaction functions” (note to whomever has control over this word, please nuke it) are written, as these have to be in nock, so if we want dynamic transactions these ought to all be done within Nock (our work on extending elixir to talk about nock can potentially allow us to do this without much pain).

I believe if we go in this direction that it’s a temporary measure until we get compilers and language designed that more closely fit the execution environment that Anoma offers. I believe developing a language like this is a natural evolution of an operating system as in order to test the operating system the repository that contains it must be able to easily call the language designed for it to test if the system behaviour works correctly. The longer and more annoying the process is to do (I.E. if the code lives in 2 repositories that depend on each other you end up with a scenario where we can’t update the standard library because a compiler written in a completely different language with many more lines of code needs to take this into account also needs to be updated, or one has to wait for long compilation for small script updates) the less likely this will work out nicely in practice. I hope in the longer run much of the anoma/anoma codebase will transition from Elixir to this in repository language.

Overall I believe this is an interesting direction to move application development to for the short term, I’m not completely sold on this move, but judging based on the usage of applications we have today, we would get a lot more easy gains in developer UX, developer debugging and program understanding. The main drawback being that we are going against the ultimate goal of having everything being in system, however even this is tempered by I believe in true integration coming in the form of something which fits the system more closely and can be integrated and consume the anoma/anoma codebase.