Design of Programming Languages

Podcast Script

Go here to see the actual podcast (requires access):

䷪ is used to mark the recording changes

Leif will be the main one talking throughout this. Any exceptions shall be marked as such.

Hi. I’m Leif Barton, and this is my podcast about the design and development of programming languages. This is episode 1/1.

** Cool sound effect ** ䷪1

First, let me share a little bit about myself, and my history with programming languages. I began programming in 4th and 5th grade. The first things I learned were how to make 2d games and how to make the frontend of webpages. By 6th grade, I was already proficient in many programming languages due to the nature of programming. Making a simple webpage already requires two elements, HTML and CSS, with more complex sites requiring the use of Javascript. HTML, which stands for HyperText Markup Language, controls the layout and elements of the webpage, CSS, which stands for Cascading Stylesheets, controls the styling of the site, and Javascript adds interactivity and complex logic to a webpage. All of these different and separate programming languages tried to achieve a specific task, and they did this very well.䷪2 Any webpage you visit will be built on these three pillars of language design, and these languages are just a few of the many. I started experimenting with embedded platforms after I learned to create webpages. This included devices such as Arduinos and Raspberry Pis, devices which run slower than modern computers but are essential for electronic devices everywhere around you. Your fridge is probably running via a microcontroller. The same goes for computer mice, vacuums, and many other devices. These microcontrollers have their own language that they are usually programmed in. This language is called C, and it is the backbone of embedded systems. If you want to interface with a microcontroller, you will most likely be using C. ䷪3 Ok, let’s take a step back. What does any of this actually mean? What even is a programming language, and how is it defined? Well, many people will tell you different things. Some will talk about it in terms of problem and solution. You have a problem you want to solve, and you use a programming language to solve it. However, that definition may be too vague 一 after all, just knowing that people solve problems with a programming language doesn’t provide any information about what a programming language actually does. To know more about this, we can look at what a programming language actually does. ䷪4 Background office noise Say Bob works for a tech company. Let’s call it… Zamazon. Bob wants to create a bit of software, something that he can sell to customers, that takes a set of transactional data and generates insights from it. How is he supposed to do that? In the early days of computers, this program would have to be coded directly onto the machine. This means that the program generated would only work on a single computer, and it would be extremely hard to modify. It would be like trying to build a mansion with only a hammer and some 2x4s. Possible, but neither desirable nor effective. ䷪5 Hammer & nail sounds come in on that last sentence, and stay a bit longer. So, what does Bob do? He’s running out of time, and investors are getting worried. Thankfully, there is a solution in place already: programming languages. In essence, a programming language takes all those nails and hammers and 2x4s and builds a excavator and some power tools. Now, the challenge of building a mansion seems a lot more manageable. ䷪6 On that last sentence, there can be the same hammer / nail sounds at the start but then it will fade into a much more modern construction site sounds. With programming languages, Bob can start becoming more efficient, reusing parts of his code in multiple places and not having to build everything from scratch. And with that hurdle out of the way, Bob gets the product completed in time and keeps his job at Zamazon. ䷪7 Some music-y stuff here Ok. Now that we know what a programming language can do and accomplish, next we should know what the basic building blocks of any programming language are. Tony Hoare, a foundational computer scientist, stated that a programming language should “give the programmer the greatest assistance in the most difficult aspects of his art, namely program design, documentation, and debugging.” So what does each of these mean? Program design is essentially the structure and thought process of the language. It is how the language is structured, and how ideas are expressed. In this way, the design of a programming language could be compared to the grammatical rules and syntax of an actual language, like English. Documentation is the next essential step. Think of it as a dictionary of an actual language: documentation, and the ease of writing it, informs the language’s users how to use a particular word or phrase. In programming languages, writing documentation is essential because if another programmer wants to use a program or function you wrote, they need to know how to use it. Debugging is the third and final basic element of programming languages. Debugging is figuring out what went wrong in the computer program. It could be likened to a modern day spell-checker or grammar checker, which figures out what is wrong in a sentence and gives you an idea of how to correct it. No large program is free of errors and bugs, which is why having a good debugger on hand is so critical. ䷪8 Another music-y break Now, we have a good idea of what a programming language is, and what it consists of. But how does such a language begin, and how can we start designing our first language? Many languages start out by improving on something other programming languages fail to accomplish. Improving on a language can consist of adding new and more convenient or better features, and identifying pain points that the first language could improve upon. ䷪9 As an example, Rob Pike, a designer at Google, took part in developing the Go programming language by first identifying several places that C and C++ could improve upon. Since Google is a large company with old roots in programming, Google primarily used C and C++ for many of their tasks. The problem with C and C++ is that they had compile times that were extremely long, and they were extremely complex. Rob Pike and a team of other Google engineers designed the Go language around this, and the end product was a scalable, fast-compiling language that succeded in every place C and C++ had failed them. Overcoming pain points like this is a staple of many programming languages. Even Python, which was created in the early nineties, was meant to combat unreadability. ䷪10 The “Zen of Python,” the guiding document for the Python language, simply states that “readability counts” and that “beautiful is better than ugly.” A final, recent example is the Rust programming language, which also attempted to solve the problems of C and C++, specifically memory safety. The next part of a language involves making some very big decisions. ䷪11 The first of these decisions is to decide whether the language is going to be functional or object-oriented. Although there are more ways to structure a language, these are the two main ways. Some languages are even a hybrid of the two, like Rust. In essence, a functional language’s job is to prevent mutability (or change) and an object oriented language embraces mutability. Both of these approaches have their upsides and downsides. ䷪12 In a functional language, the program prevents what programmers call “side-effects” 一 where a function call or action affects something completely different that the programmer wasn’t expecting. Functional languages usually do this by restricting mutability, also known as the ability to change state. This contrasts with object-oriented languages, which are usually older and try to use mutability to their benefit. Instead of having to create a copy for each new change, you can simply change what you already have to reflect that. According to the 2025 Stack Overflow developer survey, many are moving away from object-oriented to functional. However, this doesn’t mean that object-oriented programming is dead. Many existing infrastructures and programs rely on object-oriented programming languages already, meaning developers may have more experience and aptitude with a language that is object-oriented. Another choice that should be made extremely early on is whether a language is dynamically or statically typed. Typing in a programming language is basically what a certain piece of data represents in a program. This could be a number, a letter, or a whole collection of letters, which is known just as a string. Languages also allow you to create your own custom types, meaning you could create a type that represents a digital animal, a database connection, or even an entire app. ䷪13 Although every language has underlying types, languages all choose to express these types differently. A language like C++ requires types to be explicitly stated everywhere, whereas a language such as JavaScript requires no typing. The difference between these two examples is that C++ is statically typed, whereas JavaScript is dynamically typed. ䷪14 Statically typed languages attempt to rigidly set boundaries in place to prevent dangerous or unexpected conversions, while dynamically typed languages usually accept any type of data, as long as it can perform the operations on it that it needs to. Usually, the typing of a language is also indicative of whether the language is compiled or interpreted, which is another important decision. Compiled languages compile down into machine code specific for a computer’s CPU architecture and operating system. They are usually indicative of a statically typed language, and are preferred for speed and reliability. ䷪15 Compiled languages can also do something called “transpiling” which means that a language compiles into another language. This approach is adopted by languages which wish to reach a large amount of computers without having to write compilers for each architecture a language wishes to support. For example, a language could transpile to C, and since most computers already have a C compiler on them, the language would be accessible to virtually everyone. Interpreted languages, on the other hand, do not rely on compiling code but rather reading a file containing the source code and working off of that. ䷪16 These languages have very quick development time and are usually seen as dynamically typed languages because it is often easier to implement a dynamically typed language when you don’t have to compile the program. ䷪17 The next step in my understanding of programming languages was to attempt to build one myself. I figured that if I gave myself the opportunity to build a programming language, I should take advantage of it and learn the process and difficulties of making an interpreter for my very own language. So I set off to work, building, testing, and creating a language called TestLang. The README and documentation for TestLang can be found on my website, but in a nutshell, it’s a dynamically typed, interpreted language that is useful for simple scripting tasks. The language implementation itself is incredibly light, at only 414 lines of code. I named it TestLang, a portmanteau of test and language. Although lexing, parsing, and making a language may seem like a somewhat easy task, it was quite difficult. Many decisions have to go into the aspects of extensibility, parsing, and so much more. It was a good challenge and I would need more time to create a truly great language. There are also several areas where I feel I could improve upon for next time, and that I see as learning opportunities for language design. The implementation of TestLang wasn’t very fast nor optimized, so some programs would run at a very slow pace. Another item I would improve on is the scalability and maintenance of TestLang. ䷪18 At the current moment, the design of TestLang isn’t very focused on these values, which creates some problems trying to use it in real-life projects. The third thing I learned is that creating a programming language is very time-intensive. It is very involved and takes lots of time due to the nature of having to constantly iterate and improve on existing designs. Lots of time has to be spent making sure new ideas or features mesh into the preexisting ideas and features of the language. More music stuff…? And with the creation of TestLang done, and my research done as well, I feel as though I have gained significant knowledge pertinent to the design and development of programming languages. I will probably attempt to make another language in the future, and this project will have helped me out greatly. Fade out to music. ䷪19