A New Paradigm for Programming Languages

Programming these days has become a matter of learning a spectrum of different languages that all run on different runtime systems and all do their jobs slightly differently. Some programming languages, like C++ and Rust, run directly on "the metal", some, like Java and Elixir, run on a virtual machine, and others, such as Python and JavaScript, are run by an interpreter. Oftentimes the runtime environments of these languages greatly influence their design philosophies, and hence the way code is written for them, yet they often need to accomplish the same sorts of tasks. For example, to create a web server, each language has its own host of web sever frameworks to offer, each with its own quirks. It is rare for the same framework to have been targeted for multiple languages and function exactly the same in all of them. This generally isn't a problem when one chooses to develop in a single language, however many projects in the professional world tend to span multiple languages, and synchronizing schemas, APIs, and what else between those languages tends to be a problem that eats up programmer hours.

Another problem tends to be the size of codebases, which generally grow with time, and improvements to the quality and formatting of existing code are rarely prioritized over the addition of new features. Some common refactoring tasks include renaming a particular symbol and occurrences of its name in comments, renaming an entire component of the application, updating a method call to include an additional argument, and swapping out a backend. While some of these tasks a more involved, a common theme among them is text replacement, which is something a programmer will do a lot of in their career. This can be automated by a program that parses the text files and deduces which bits of text the programmer wants to rename, it is oftentimes far from perfect, and some manual searching and refactoring can be necessary when typos, hard-coded string literals, and multiple components with overlapping names are involved.

In my opinion, these two problems--the fragmented landscape of programming languages and the problems caused by naming and renaming--are two major problems that bog down the efficiency of programmers today. That being said, I would hate to further fragment the landscape by introducing Yet Another Amateur Programming Language, as catchy as YAAPL sounds. However, I think there is room for change, and at the very least I would like to introduce a design for what I think could shape out to be a universal programming language. For the sake of convenience, I will refer to it as Everlang.

Naming Conventions

To address the refactoring problem, identifying constructs in Everlang by a short string of text is a thing of the past. The way to identify things in Everlang is by a Unique IDentifier, or UID for short. The reason is simple: this almost wholly removes the need for the resolution of identifiers and is easily hashable, meaning there is less burden on programs trying to refactor Everlang code. It also gives no reason to rename things once things once they are created, so there is no need to contemplate a good name for something only to laboriously change it later. Furthermore, UIDs can be scoped by project, library, or module, reducing the chance of conflict. As it is impossible to know what a UID identifies from merely looking at it, Everlang also encourages the programmer to annotate their type with a human readable string that may be changed at any time. This is what gets displayed to the programmer in the code editor. Shifting the burden of identification from the human-readable name of something to a UID gives more flexibility to the name in that it can be changed without refactoring the code, and in that it can even contain spaces and punctuation. This is something that is already done in databases when identifying data, and there is no reason not to apply it to programming. UID identifiers are applied to functions, process state, and data types, but are not used for local variables which are easily resolvable in their local scope.

Logic: Functions and State

The main unit of logic for Everlang is the function, much like it is in many functional programming languages. Unlike purely functional languages, local variables inside the function may be used to perform any logic necessary, similar to Elixir. A function in Everlang takes positional arguments, which may always be specified out of order by UID. It may also pull and even require contextual arguments from the process state. The process state is a dynamic structure separate from the call stack that represents the entire state of a single process (a process being like a thread). It travels with the process through function invocations and is only garbage collected when the process exits, or when it is cleaned manually. This state may be modified by both the programmer and any libraries used; therefore to avoid name conflicts, UIDs are used. In a sense, this state accomplishes the same thing as thread-local variables in other languages, however it allows different related parts of code to communicate without putting the burden of passing return values to further function invocations on the programmer.

This is the extent of how functions and state work in Everlang. It may seem simple, and it is, but all of this is done with the end goal of better code maintainability. It does beg the question of how code is organized in Everlang, and that I will address next.

Code Organization

Traditionally, code is organized into files which contain entire modules or parts of modules. These files are thrown into a directory structure that is intended to help the programmer find code related to a particular component. While this is well and good, Everlang does not take this approach. Instead, code resides inside a single project file, and functions are organized by tags. Tags are identified by UID and represent discrete components or areas of logic in the application. The advantage of using tags over a directory structure is that the programmer does not need to concern themselves with how easily navigable or clean a directory structure looks. Additionally, new programmers to a codebase do not have to learn its directory structure, only what tags will help them find the function they are looking for. While this may seem like a radical approach to code organization, it comes with its advantages and deserves to be tried.

Reducing Fragmentation: Compile Targets

As mentioned earlier, one of the goals of Everlang is to reduce the number of technologies one needs to concern themselves with when programming. However, sometimes it is inevitable that we need to work with technologies we do not intend to. To address this, Everlang supports transpilation to languages such as JavaScript, Java, Python, Elixir, C++, and more. While this does not produce idiomatic code in those languages, it does produce typesafe code, and more importantly code that stems from a common language, meaning the need to manually duplicate data schemas in multiple languages no longer exists. There is also no need to have separate package managers for each language, as all code in the codebase will originate from Everlang. This significantly reduces development time in codebases that would traditionally use a multitude of languages.

Easy APIs

With support for transpilation, Javascript APIs could also be a thing of the past. Instead of communicating with JavaScript code from Python, for example, native Everlang code can communicate with Everlang transpiled to Javascript in binary over a TCP connection. This means, in essence, that arbitrary functions can be called between different Everlang runtimes synchronously or asynchronously with minimal effort on the programmer's part. While languages such as C++ already have constructs for doing this, there is yet to be a solution that works for completely different runtime systems. This makes Everlang a truly powerful language for web and multiplatform development.

In Conclusion

So far I have described to you a language that does not exist. I've proposed some ideas that may seem radical to some, but that I hope may pique the interest of many. The idea of a language that could trump all languages is probably nothing new, but it has yet to be given a serious attempt. I believe if what I have presented here is implemented correctly, it could be a very powerful tool for developers in the future and greatly speed up development time. We simply need to break free of the perspective that modern languages and development practices have confined us to and push for a better development experience for all.

(Note: This was written for a school assignment. There are more details I would like to explore but have not had the time to go into here. I may update this post in the future or expand on it elsewhere.)