The Platform is The Language
The Platform is The Language
Platforms are controlled by their language.
This newsletter is here to share what Marcus and I think is interesting: thoughts, cool demos, etc. It is sent irregularly to the people we have a relationship with. This means I either emailed you or you emailed me.
You can opt out at anytime (bottom link) and you won’t hear from us again.
Introduction
Working with programming languages is a weird activity. There is no market around it yet every programmer use them. It looks like a “nerdy business”, an activity for people like us who love to obsess about things. It turns out that languages are the key to controlling one of the most lucrative opportunity of the computing era: platforms. In this post, I am explaining how a platform works and why its language is its key.
Platforms
We don’t use computers directly. We use a platform. It is “something” built on top of the computer to “do something”. For instance, browsers are a platform to execute applications hosted on the cloud. Android is an operating system used to execute the same type of applications in a mobile context.
Why? Mobile has limited bandwidth, specific capabilities (e.g. GPS, accelerometer) and requirements (e.g. battery use, emergency service). The connection can be spotty which implies programs need to run locally. Browsers have a much higher bandwidth and more CPU. Because of that, we can download the program each time and communicate constantly with the cloud. This is our first learning: platforms are built to mitigate and manage real world constraints. Platforms deeply reflect their technical constraints.
NB
Platforms are mixing all the time. E.g. when you use Chrome on Android you are part of two platforms: Android and the browser.
A platform’s lifespan can be predicted from its technical constraints. The cloud might get killed by the deployment of symmetric last mile data link (i.e. optical filber vs ADSL).
A platform needs users and developers to function. From a business angle, platforms are a marketplace where users download “stuff to do on the platform” (e.g. app) and where developers build them. As with all marketplace, there is a chicken and egg problem: to acquire developers you need users and to acquire users you need apps built by developers. There is a well known solution to that problem.
A killer app (usually built by the platform owner) will drive users to the platform. In the case of Windows, it was Excel. An already successful application that got moved to Windows and ensured its success.
Users flock in because they want to use this application.
Developers come in because there are a lot of users
Go to 2.
Another example is crypto: the killer app was created (get rich fast), users flocked in and now developers are trying to find other use cases.
The Real World
All of that is nice but it’s very abstract and “businessy”. Let’s look at a platform from a technical point of view.
A platform is:
a “computational system” (e.g. a PC, a set of VM on the cloud). Everything to execute programs and what’s around (e.g. storage, display, network, …).
an SDK and utilities. It’s a set of libraries to use these computational units.
a language that uses the library easily.
The language and the SDK a close to each other. It’s not that easy to define where one starts and where the other is.
This Kotlin code starts an Android new screen (i.e. an activity). Where is the language? Where is the SDK?
val intent = Intent(this, NextActivity::class.java)
// To pass any data to next activity
intent.putExtra("keyIdentifier", value)
// start your next activity
startActivity(intent)All languages are Turing complete . You can use one or another for the same task. What matter is how easy it is to “do a job” with a language. This is its expressiveness and semantics. With Java, managing hundreds of threads is possible but hard. With Kotlin, it’s fairly trivial yet they’re both JVM languages.
Again, this is all already known but the language here is usually overlooked.
For instance, with Android:
The computational unit is an ARM SoC with a screen, a battery, and Internet connectivity.
SDK: the Android Framework UI, network, optimize battery consumption, etc.
Language: JVM based language (Kotlin and Java) and an interface for C/C++ when you need performance. Its bytecode can run on most platforms, a lot of libraries are already there and its well known how to optimize its execution.
NB
The SDK is usually built using the language. That is our first hint about the importance of the language.
Actually, platforms run several languages, but they’re usually very similar in their semantic e.g. Java and Kotlin.
In practice a platform is built around a language and its ecosystem. They influence each other; they’re indefectible tied to each other.
The Map is the Territory
The language of the platform defines the “worldview” of the platform and it structures what it can do. The “real world” will influence in turn the development of the language and its ecosystem to reach the point where both are the image of each other.
Javascript is arguably the language of the Web. It has language level constructs to secure/download/reload code and manage dynamic code. This is why we can download a code from another website and execute it. This feature is widely used to display advertisement and track users. It also implies libraries are grouped on distant servers (aka the cloud) and that the language is very dynamic.
The latest Android devices runs 8 to 16 cores vs 2 to 4 for the previous generation. Nowadays, a random Android app has over 100 threads. App developers need some features to manage them. That’s the key evolution of Kotlin and why Android switched to Kotlin happened (another explanation is here). Kotlin allows more possibilities to “talk about threads”.
Kotlin is an open source language not even owned by Google. The Android framework is also open source. And, nor Kotlin, nor Javascript, generate revenue. In that sense, a language is a weak asset. Yet I claim it is the heart of the platform and the key element.
A programming language carries a set of semantic well tuned to the platform. It’s a convenient way to “do the job”. For instance, how would you “compose several websites” without Javascript? You’d probably end up somewhere close.
Because it’s the interface of the system, you only can make on the platform what you can say with the language. And vice versa. It doesn’t matter who own the language. Java is owned by Oracle. This never prevented Google from making a lot of money with it.
The language influences the platform and what is less obvious is the platform influences back the language so it can better express the platform. For instance, during the browser wars, platforms added Javascript constructs to differentiate each other. That evolved the language significantly so it could support complex web applications.
So languages embody the platform and they don’t fare well outside of it. E.g. React Native on mobile. It works but it doesn’t supplant Java. Java came from the server but was heavily altered to work on mobile (e.g. new execution model, removal of instructions, new libraries, …). With Kotlin, Android won a language where you can manage the hundreds of threads of an application.
Language embeds a vision of the universe. It mediates what the application does; It structures what it does and more importantly what it can do. This means to evolve the platform you need to evolve its language. This is what Google achieved masterfully by moving Android to Kotlin.
Platform Creation Example
Let’s try to build a platform “virtually” on top of Ethereum. The steps are:
create a killer app that uses the “killer feature” of the new platform
open it to other developers attracted by the users that the killer app has amassed
The killer app I want is a home insurance running as a 100% open model i.e. I know how much money the fund has, how much it pays out, etc. The transparency is the “killer feature” as a lot of people encountered a definitive lack of transparency in that space.
NB
InsureDAO and NexusMutual are insuring smart contracts but not the “real world”. I want to insure the real world.
My killer app needs to:
add subscriber (define what is insured, prove it, pay, ...)
process claims
To insure a home you need to provide the address and describe the valuables with proofs (e.g. receipt, pictures). But everything is public on Ethereum and I don’t want to make public pictures of my valuables and their value to be used as a shopping list for burglars. And a human needs to review the pictures and the invoices to validate them. I need to extend Ethereum to manage some private informations on a secondary auditable Blockchain where the data is accessible only by authorized people and the data can be deleted on the chain once the contract is completed.
Stumbling onto that use case, I realize that the “everything is public” paradigm of Ethereum prevents some applications to be successfully decentralized and to be run from it. That limits is built deep into the language stack.
So I’ll fork Ethereum and add these two (very difficult) features and add two keywords to its language Solidity:
delete_private: delete a private key retroactively in the blockchain
create private user: create a “secret” chain where only a subset of users have access
store_private: store on the private chain the data
This will make my chain incompatible with Ethereum but my users can still use Ethereum. I can tap into their user base to migrate them to my platform. And other developers can use these new keywords to build their own application on top of my chain!
This is a trivial example. Yet I extend the language and a lot of cascading effects happen:
I deliver an app impossible with the current platform
Users will flock in. (That’s where the risk is.)
Developers will want to build new secret feature on my chain.
Which mean more users will come.
Etc.
Conclusion
To paraphrase Alan Kay, if you’re serious about applications you need to make your own platform.
Programming languages are the most important element of a platform. Influencing it mean you influence the platform.