Programming predictions for the next decade

Before we get too far into 2020, I thought I’d make a few predictions about programming for the next ten years. These are things that I think will generally be true by the year 2030.

Language Interoperability

There’s going to be a rise in language interoperability. The problem that will drive this is the desire to build big, complex, and useful software that runs anywhere with native speed and features.

Doing this in 2020 is possible, but ridiculously complicated. It involves a Rube-Goldberg-number of parsers, generators, tools, frameworks, plug-ins, scripts, and configurations.

Using a single language or framework could really increase the speed and number of things developers can build. There will only be more teams shipping more web things, so I think there’s a need here. The more people that need to figure out how this should work, the closer we’ll get to fusing the IDE, compile, tools, and programming language into one thing.

What will this look like in practice? It might look something like a meta-programming language that lets you drop in an out of different languages, markups, and DSLs, compiling them to multiple targets.

In theory, if not in practice, you can already do something like this with Rust macros.

js! {
	let root = document.getElementById("root");
	// ...etc
}

css! {
    body {
        overflow: hidden;
        padding: 0;
        margin: 0;
    }
    /* ...etc */
}

Or you could use a well configured IDE, but it would really be simpler to have them both merge into something that gives you write-time, compile-time, and run-time advantages all in one.

UI Rendering detached from logic further

A UI is a cluster of conflicting interests. It has to make sense to the user (something that often is at cross-purposes with how its structured), it has to integrate with your data model (something that is often at cross-purposes with how the data is store), and it has to be change-able over time (something that is often at cross-purposes with everything.)

This often leads to the Model and the Controller in MVC leaking into the View, until it’s difficult to tell if there was ever an Model, a Controller or a View.

One way to fix this is declarative UIs. See also this.

Languages like Elm made some progress on this front, and it’s possible that in another decade we’ll see the idea taken even further. This could look something like a library, language, or framework that lets you declare a tree of data to be rendered, along with paths of the tree need to be in sync, and give it to a rendering library. In return you get some hooks and references, which act as application state channels to push new values to the view.

Really what I’m getting at here, is a sort of Unreal Engine 5 for UIs. You just give it a scene or a view, and it handles all view state changes, with small hooks to pickup those state changes, and handle input.

Language Servers

Language servers will become more prominent.

Instead of defining a surface area of a server with an RPC framework or REST, it will be defined with something like Microsoft’s VSCode Language Server - where the language services can run on any platform, web, native, back-end, and one of these platforms is responsible for persistence. It will allow programmers to extend command-like capabilities over the products they build. Instead of controlling the REST surface area, programmers will write features manipulating the business logic directly on the “language” or document itself, rendering it as something else to the user. This will also make collaborative work, or rather, document synchronization, easier.

Basically, it’s easier to define a document, the interactions, migrations, and collaborative syncing than it is to build an entire granular API, and services on top of it.

A simple example of this could look something like a JSON Schema, with a light framework on top of it, defining how it can change and which clients (read: users) should pickup the change.

interface X { /** JSON Schema here. */ }

interface Migrator<X> {
  Migrate_Build_2020_4_30(from: X) : X;
}

interface Synchronizer {
  PeerToPeer(op: CrdtOperation) : RPC;
  Record(op: CrdtOperation) : RPC;
}

Almost Automation

The need to do things with data will outpace even high-tech organization’s capacity to build programmatic features, leading to a rise in the number of pseudo-programming tools that people will use to solve problems. This is currently being done with Microsoft Excel, and other forms of spreadsheets. These types of tools will continue to fill the gaps between systems, and human beings will operate them in ways that are resistant to automation.

Low-code and no-code will largely stay the same - they’re really just slower ways to build something with code for people who understand logic, but don’t know how to code. If you know enough to build something on a low- or no-code platform, you’ve had a taste of what engineering is like, and you’ll quickly move on to building things with professional tools.

For this reason, it’s hard to tell if there will be a “big” low-code platform. They’re selling an idea of productivity, but it’s hard to tell if that’s what the buyer gets. They will all have feature lists that are something like:

• “Plug-this-into-that” logic building.
• Flow control that looks like a graph.
• Support for all the big services, DBs, APIs.
• Support to write your own plug-ins.
• No way to eject the code, or export your configuration.

All of them are banking on locking the user into something by getting the patterns right. But hitting those patterns is a challenge that all existing SaaS companies already face: balancing complexity with focus. What’s more is that, in addition to getting the balance right, the low- and no-code tools have to contend with letting the users endlessly configure their applications. That’s not to say it’s impossible; but it’s hard to see who will get it right and how, because a lot of engineers haven’t figured out how to do it with their own code, let alone a platform.

The Super-Trend

The super-trend here is the coalescence of programming languages into meta-languages that lets programmers target specifications rather than write in languages implementing those specifications. The ability to drop into and out of another language in one file or program is attractive because it reduces the number of frameworks, files, and tools you need to build something. But these languages have not quite caught on yet.

I think this trend makes sense because it runs parallel to the trend of platform maturation. The web, alongside device-specific software, has all come to a point where most pieces of software could be run on any platform. You can compile for multiple platforms, so it appears to users that your software looks and feels the same across those platforms and devices. But the experience of building software doesn’t reflect that virtualization.

In ten years, it will still be the case that a user can run anything on any device. It will hopefully be the case that an engineer can build anything in any language, or maybe just one language.