The future of programming

Here’s my quick and dirty prediction of what will happen with software in the future. The goal if this writeup is to collect feedback and spark discussion. Many of the statements can be purely wrong - please take them with a grain of salt.

Prediction starts from point 6.

The bottom-top listing of ways of creating (computer) programs:

1. Programming hardware with a firmware
   1. Firmware can literally be part a hardware. I’d consider mechanical engineering as a form of programming too. The way the physical object is built determines what it can or can’t do.
2. Language directly executed by hardware.
3. Compiler to language under point 2.
4. Many languages we know: C, Java, Haskell, Java and JavaScript, etc.
   1. All paradigms and styles with all known patterns, including and not limited to:
      1. Procedural
      2. Functional
      3. Logical
      4. Classes and instances wrongly a.k.a. OOP - this is not OOP in meaning we’re talking about here
   2. Those languages usually work on data contained within one process within single operating system with heavy use of IO.
5. Object oriented programming (OOP), where:
   1. Objects are computational units, they can be:
      1. In-process routines - threads, green threads, any other form of self contained units
      2. OS process
      3. Computer
      4. Network of computers
   2. Objects communicate using only messages:
      1. Message is an immutable data
      2. It can have a format/spec, but doesn’t have to
      3. Message can be send from object A to object B
      4. Object B doesn’t have to react to a message, doesn’t even have to understand it
      5. Object A can get response from object B only by asking for it, it’s up to object B to deliver it knowing the sender.
   3. Examples of OOP systems:
      1. The Internet with all devices connected to it,
      2. Erlang VM,
      3. Actor systems in different languages
         1. Messaging systems, brokers, queues - those are parts needed to engineer true OOP systems.
6. Repetition of all languages known in point 4, but this time working on a higher level of abstraction
   1. Function call, read and write are a message from current object to itself or to any other object (object in a sense from point 5.).
   2. IO is also about sending messages to objects, some objects simply can represent physical devices.
   3. Byte code or intermediate representation can be interpreted in a similar way to what currently Ethereum does - but doesn’t have to. This represents language in top-level point 2.
   4. Hardware from point 1. is now some object which emulates physical computer.
   5. New protocols are needed to emerge:
      1. What is the universal language describing messages?
         1. Not possible to create one, there needs to be a mediator/negotiator/translator describing capabilities of objects. Similar to human speaking languages - there are translators and there must be always at least one language speaker. Otherwise the language knowledge is lost and have to be rebuilt somehow.
      2. What will be the minimal language to use?
         1. It’ll be some form of lisp, but it’s not about parenthesis - they’re irrelevant, it’s about evaluation and application of arguments to a procedure in the context of bound names.
         2. The first program to write will be meta circular evaluator of itself, it’ll be the base of all other programs and will make easy to implement all other needed abstractions.
            1. It’s true even today - metacircular evaluator should be at core of many languages and libraries and could be compiled away for achieving better performance characteristics. But it’s not as it’s forgotten mechanism.
   6. It’s quite easy to notice that the message in OOP is analogous to writing bytes in physical CPU. Writing bytes doesn’t create guarantee there will be a response (or form reaction), so the act of sending message in OOP.
   7. It can be noticed the WASM is a form of abstracting away the hardware - all compatible languages can be ran by anything that executes WASM programs.
7. Point 6. can be repeated arbitrary number of times, for example creating next layer can be useful for debugging previous layer. Or to create reporting/observability/security layer.
   1. All the layers will be possible to collapse and create single program known in top point 2., 3. or 4.
8. ???

What are the benefits of programming in style from point 6. and above:

• No need (or much, much, MUCH smaller need) to create glue code and plumb different systems and libraries - they’ll communicate using messages translated by mediator/negotiator,
• No need to create multiple debuggers and development tools - one usually will be enough and will be mapped to other languages/systems - running procedure with arguments in controlled way and evaluating some block in some environment is an universal mechanism,
• In general, there will be no need to create most of the things more than once - they will be transferrable to different systems as long those systems understand (have a translator) messages exchanged by the other system,
• Many things we struggle today because we do it without OOP system, will be simple after using OOP correctly and new layers of innovation will emerge,
• [Dragons!] I’d say order of magnitude faster development times - hard to say how many orders there actually will be and what’s the maximum number of orders.

OOP is probably a wrong name, but it’s quite widely known because of the work of Alan Kay. I think OOP is about generalization of computation where real hardware is stripped away and is just a detail for some particular instance of „OOP” system.

As I said, I rather want to share my intuitions, not to create a system manual or learning material. Thank you for reading through!