What is FREST?

FREST is simpler computing for ordinary folks and programmers alike.

Frest is currently a software design philosophy, or you might say a “pattern”. Code will be coming in due time.

Computing today is composed of finely interwoven layers of great abstractions and horrible cruft. The relational model and SQL. URLs and the filesystem. Direct manipulation of abstractions with a nice GUI, and rolling yet another HTML form by hand.

FREST isn’t radical. Or rather, being radical isn’t really radical. The history of the computing industry is one of radical experimentation leading to radical change, in a kind of punctuated continuum. The radical idea becomes mainstream after the crazy pioneers have proven it.

Today’s most popular programming languages put ideas that were fringe and theoretical just a few years ago right in your face. Advanced type systems. The Actor model of parallelism. Synchronisation of distributed data. AI.

Before Typescript, advanced type systems were largely the stuff of academic papers. A couple of years after Typescript’s release, advanced type systems are suddenly everywhere.

The computing industry is in a constant struggle between worse-is-better and, well, better-is-better. There are both good and not-so-good economic, cultural and engineering reasons for our industry’s conservatism.

This project seeks to go where the puck is going much faster. There are a small number of mature ideas we should adopt in one go. In particular:

1. The network is the basis

Everything important is addressable and serialisable. Every field in every table in your database. Every high-level function in your business model. Every conceptually distinct element in your UI.

In FREST, the filesystem isn’t the starting point. The filesystem isn’t even necessary¹. Addressable content is the better way. Even within single applications, major articulation points should be connected by URLs².

Even code isn’t loaded from a file; it’s at an address. Everything is at an address.

2. Direct manipulation of abstractions

The most successful products for non-programmers to do computing are those which allow folks to directly manipulate highly expressive abstractions.

FileMaker and Access (and these days, say, Notion) are end user relational data bases with some functional features. It turns out that when given a nice GUI for manipulating such things, non-programmers can employ relational database concepts with considerable facility.

Then, consider spreadsheets. Spreadsheets let non-programmers do functional programming. Spreadsheet jockies don’t use variables; they use values at addresses. Few have heralded the amazing news that Microsoft recently added an easy to use Y combinator to Excel. Excel was already the best product Microsoft ever made³.

Non-programmers, it turns out, can do effective functional and relational programming with minimal training. Why did our industry keep trying to push “simple” imperative programming paradigms as computing for non-programmers? Visual Basic is fine, but where’s Visual Scheme?

One of the main questions FREST seeks to ask and answer is: What other highly expressive abstractions can we present to non-programmers in an intuitive way?

The FREST project’s bet is: quite a few: actors, encryption, append-only data stores, logic, …

Note that the features of a typical business application that are amenable to this approach are almost precisely those that compose the grinding tedium of everyday corporate programming. So this is very much about making lives easier for developers as well.

3. There’s always a GUI. Always.

Excel and FileMaker let users directly manipulate abstractions, always with an appropriate GUI presentation (even if it’s just a textual function editor).

Everything addressable in a FREST system is able to present itself in any of a small number of composable ways, such as:

• icon

• descriptive link

• table cell

• table row

• table or form header

• “full page”

FREST is agnostic about its presentation layer, just requiring that there should be one. Most obviously in the first case, FREST would probably present HTML versions of these things, perhaps as Web Components.

This sort of collection of presentations is sufficient for robust and subtle embedding. For example, a table can be embedded as an icon or descriptive link in some richer context — an outliner, or a web page element, or an object in a drawing program. Within those UI paradigms, the content can be expanded and manipulated.

All that a programmer has to do if they introduce a new type is to provide those presentations of it. Usually, this can be done through existing presentations. A programmer who writes a function need only describe its input and output types (and any security constraints) and it will be available to use anywhere applicable, through the GUI or the API.

The industry has tried several times (eg Apple’s OpenDoc and Microsoft’s COM Objects) to enable embeddable live content. FREST bets that modern web and other technologies provide an opportunity to do it right this time.

Consider introducing a really novel content and presentation type — an outliner, say. The author of the outliner can write the outline presentation and manipulation logic and storage, and then trivially support any other content at all within the outline. An outline node could be a table that can be collapsed to an icon and expanded at will.

4. The UI is always navigable

FREST content might present all sorts of interesting buttons, menus and other chrome for interacting with content. But at the very least, every FREST value responds to a right click or long press or the like, presenting a meta view of the thing the gesture is addressed to.

There will in time likely be all sorts of semantic, pragmatic and other content on the meta UI. But at the very least initially, the meta view will allow the user to discover and invoke all the things that can be done with the value. It lets the user switch between the standard presentation and others (a table of data might be viewable as a chart, for example). It lets the user choose between functions that take the value as an argument. This might create a new single value, or a new column in a table.

5. Functional Programming

If ordinary folk can do functional programming, and professional programming languages are all turning into LISP/Scheme/ML, then FREST will too. The addressable functions of which a FREST system is composed include functional programming constructs that allow composition of existing things into new things.

I’ll discuss this in more detail later, but briefly:

• partial application is central;

• functions present themselves as forms;

• user interface elaborations are preformed through functional operations, for example, starting from a table of addresses, a user can add a column of maps of those addresses, which is to say the user applies a (functional) map operation to the data underlying the table;

• API operations are functional programming operations. API clients can create new values, including functions

• API operations are asynchronous. If a client of an API wants a value, it passes an address for the return value to be sent to. FREST is a continuation-passing architecture. This means, for example, that any function call can be a remote call back.

6. Relations

Functions are user-friendly, but relations are much more so!

Try to forget SQL. I’ll have a whole ’nother rant about that later. Just think in terms of simple relational operations such as you might use through the user interface in Access or FileMaker. Joining relations, querying them, obtaining new values through functions of old ones.

SQL has poisoned our entire industry. Relations are elegant and beautiful and it is possible and fruitful to represent much more of our software through relations. Any aspect of software represented relationally is simpler, easier to get correct, and more fungible than it is through a traditional programming language.

FREST says APIs should be relational. GraphQL is our industry already heading in this direction. The result is APIs of much greater subtlety, flexibility and efficiency. More on that soon.

7. Composition and Security

Security and composition are two sides of the same idea in FREST. This model will be described in a separate piece soon.

Briefly, a client of a FREST system is faced with values (which might be functions, rows, whole relations, addresses, anything at all) that are missing, that are provided as a default, or that are fixed. The client can provide or override any value that isn’t fixed.

This is why even the internal relationships within a FREST system are accessed through addresses: so they can be externally overridden.

Many things will have a default value that can be changed. Most of the logic and layouts of UI generation will be a default. Many behaviours will be defaults. The user will be able to right-click something in their UI, navigate all the defaults that produced that thing, and change any of them.

This is where the relations comes in. To take just one example, the sequence of operations that occur when you add an item to your shopping basket should be described in a relation, not buried in code.

Imagine if you could customise your Amazon user interface by right clicking and removing things, surfacing things that are hidden, changing the actions when an item is added to a shopping basket, and so on. FREST promises to make software like that easier to write than the current rigid Amazon experience was to write in the first place.

In Summary

FREST is a set of protocols that define network-first, relation-first, GUI-first data manipulation and programming environments.

Work is underway on example implementations in more than one language.

FREST is about to change everything. Stay tuned.

---

1. In all of this, we’ll build on what we have, at least initially, so early FREST systems will exploit filesystems and SQL databases and the lot. But systems have been built without a traditional filesystem. A great example: BeOS’s filesystem was also a relational database, and was much the better for it.

2. We’ll discuss why in due course.

3. Excel is quite a bit of engineering, but why can’t anyone make a better word processor than Word? I just need a nice UI with tables and basic layout and stuff, and strong style sheets. Word is just okay on these criteria, but everything else I’ve ever used isn’t better.