The end of programming?

While this blog has so far been mostly timeless, I'm going to comment here on a current event: an article arrived today in my mailbox, titled "The End of Programming"^* and subtitled, "The end of classical computer science is coming, and most of us are dinosaurs waiting for the meteor to hit," written by Matt Welsh.

I'm arguing that the use of PicoStack to develop small web applications could continue, long after most computer applications are developed using artificial intelligence (AI) techniques, and code is being written routinely by AI agents instead of humans.

Managing channels

A previous post, Pico channels, defines and describes channels, and prescribes some best practices for managing them. 

This post tells a story of bad consequences when that advice was ignored^*, and also describes a more resilient way to set up the channels for one particular application.

Consider a pico that records temperature readings from remote sensors. The sensors need a channel to post their readings periodically. A web application allowing the history of those readings to be explored also needs a channel to the pico.

Notifications

Each pico, from the moment it is created, is a first-class Internet resource, exposing a rich API of events and queries. It maintains a boundary between its internal state and the outside world.

When something interesting happens inside the pico the owner/controller of the pico may want to be notified.

A previous post about sending email illustrated this for that notification method. In this post, we'll discuss sending a message into a Microsoft Teams channel. Similar techniques can be used so that our pico can notify other message systems.

Scheduling events

Picos are a good fit for applications that have a relatively small amount of state for each entity, and that perform relatively quick computations, relatively infrequently.

Web applications fit that profile. From time to time, someone requests information about the state of an entity. That state is expressed as a web page, and that doesn't take a lot of time to compute.

Every so often, an event occurs that is of interest to the entity, and the pico reacts to that event by changing its state, which also doesn't require a lot of compute time.

Sometimes, though, we'll want the entity's pico to spontaneously wake up and do something. This is where scheduled events come into play.

Sending email via a web API

This is part four in a series^* on using web APIs to accomplish useful things in a PicoStack web application.

We have talked about consuming web APIs in a read-only fashion, safeguarding web API secrets when they are required, and wrapping the complexity of an API in a ruleset used as a module.

In this post, we'll use all of these techniques and demonstrate how to use a web API to send simple text email messages.

Wrapper opportunity

When using a web API it can be nice to have a wrapper around the various HTTP requests that can be made.

On the plus side, this allows for a separation of concerns. Your code doesn't need to get into the details of making the HTTP requests.

Often, the provider of the web API also supplies wrappers for various popular programming languages. Some, like TMDb (used in the previous post) accept wrappers from their developers and list them for use by other developers.

Web API secrets

In the previous post, we consumed a web API which was provided freely (which we called "public") in that it didn't need to know who we were. Most web APIs require consumers to identify themselves, and do this by giving out an API key and/or client secret.

The identifiers we will obtain from an API provider are intended for our use only, and we are responsible for that usage. In this post, we'll show a couple of ways to keep them secret while we consume such APIs.

Consuming web APIs

There are countless thousands of APIs provided on the web. Fifteen percent of them are public^*. A web application can consume private ones once you have signed up with the owner of the API and been given client API keys and secrets.

Either way, PicoStack is an easy way to consume these APIs.

In this post, we'll walk through using one particular public API, which provides information about events held at Brigham Young University (BYU).

Website Certificates

Your website will need a certificate if you want to use TLS to encrypt traffic so that it cannot be intercepted and read -- or worse, modified -- as it flows from a browser to your picos and vice versa.

If you elect to use TLS, the browser will show your visitors that your website is "safe"^* because your URLs will be able to use the HTTPS protocol, rather than the unencrypted HTTP protocol.

To use TLS, you need a certificate which offers proof that you control the web server which hosts your picos and hence your website. A certificate authority will issue you such a certificate after verifying that you do indeed control the web server.

Session information

A web application, when in active use, is a large decentralized system. Thousands (and hopefully more) of participants, each with their own machine running a web browser, are generating events to -- and requesting resources from -- the web server portion of the web application.

It can become centralized if the web server controls who can access the web application. This doesn't have to happen; it is a decision (whether consciously or unconsciously made) by its designers.

Relationships between picos

In the previous post, we described pico channels. When you have the identifier of one of a pico's channels, you can use it to send events and queries to that pico.

When a pair of picos need to work together, each needs an ECI (event channel identifier) to the other. The bundle of that pair of ECIs reifies a relationship shared by the two picos. Each pico has its own copy of the bundle.

Pico channels

When we say that a pico is "on the Internet" we mean^* that it presents an API to the world. A key part of every API request is an Event Channel Identifier (ECI) for the pico. It is a random-looking string that gives access to and authorization for each usage of one of its many^** APIs.

Each pico can have an unlimited number of channels. Each event and query comes into the pico via one of these channels. Each channel has a policy, listing which events and queries will be accepted over it.

Picos and persistent state

This post provides specific detail to follow up on an earlier post about picos as the database of a web application.

Each pico holds persistent state, which is data or information specific to whatever entity it represents. Even if the pico engine which hosts it goes down temporarily, the state will be there as soon as it restarts.

The pico state is held and managed by the rulesets installed in it. Each ruleset can hold a portion of the entire state, and since there is no limit to the number of installed rulesets, the total quantity of data is also not limited.

Picos and computation

Picos are persistent objects living on the Internet. They also can do computation. However, they work best when a limited amount of computation is required to react to each event, and to respond to queries.

Most web applications fit this pattern well. They need persistent state, including sessions. They need to be on the Internet and readily available. They need to respond and react very quickly to actions taken by the persons using them.

Layering rulesets in a pico

Once we have created a pico, we can begin to add rulesets to it. Each ruleset we install adds another  layer of behavior and persistent state.

A stateful web app in a pico

In an earlier post, we showed a simple web application in a pico. Each time that application is requested, it produces a different page, but it doesn't maintain state from one request to the next.

Here we will discuss a simple application that allows a visitor to select their favorite color. Once the selection has been made, each time the page will show that color, and allow them to change it.

This demonstrates the way the Pico Stack persists state without needing an external database.

Picos as the database

Picos can be used as the database layer of a web application. In fact, the pico developer UI is such a web application. So is our Manifold project^* at Pico Labs. Both of these feature a front end running in the browser (written using the ReactJS framework (and so are single page applications^**)).

Typically when using databases, an application program retrieves the data from a row into memory, thus bringing the data to the code. With picos, we bring the code to the data, by installing rulesets in each entity pico.

Are picos object-oriented?

We've established that a pico is an object. So, is KRL (the programming language used in picos) an object-oriented language?

Object-oriented languages can be divided into two camps: class-based and prototype-based. Among the class-based languages are Smalltalk, Java, etc. On the other hand, Objective C, JavaScript, etc. are prototype based.

A first web application in a pico

In the previous post we showed an example of a web application program which has HTML inside of it.

And, we showed a web application program which looks like HTML but contains bits of program inside of it.

Here we compare the latter program with one written for a pico.

HTML inside or outside?

A classic web application is a program that runs on the server and generates a character string which is valid HTML. It is hard to imagine a programming language that could not generate a string of characters, so any programming language should be able to do this.

Let's look at some examples.

Application delivery then and now

Traditionally, software applications have been written in some arcane textual language and machine translated into a binary language, with that bit stream installed on the machine where the application must run.

By "arcane" is meant that while the textual language is human-readable, it is only comprehensible to trained software professionals. The remaining steps of translation into binary and delivery and installation in a machine are also professional topics.

Web applications, from the beginning, are different. 

Anatomy of web applications

 In the previous post, we suggested that picos and KRL can be used to create web applications.

Structure of a web application

The diagram shows a simplified web application architecture.

Picos as a web application development stack

This blog explores a novel computing technique for creating applications that run on the web. Picos can be used for this purpose and, by themselves, provide a complete web app development stack.

What is a pico?

Picos are persistent objects with computational power and a rich Internet API. As such, they can be used to create web applications.