"To understand is to perceive patterns." - Isaiah Berlin

Math is not just numbers. It is the science of finding complex patterns that shape our world. This means that to truly understand it, we need to see beyond numbers, formulas, and theorems and understand its structures.

The main goal of this article is to show how math is just like a growing tree of ideas. I want to show that math is a living system of logic, not just formulas to memorize. With analogies, history, and code examples, I want to help you understand math more deeply and how you can apply it to programming.

I’ve also included some code examples here to help you connect theory and practice. I show them to demonstrate how math ideas are applied to real problems. Whether you are new to more advanced math or are more experienced, these code examples will help you understand how to apply math in programming.

This link across theory and application reflects my own studies. I am a finalist in an undergraduate degree in Electrical and Computer Engineering at NOVA FCT, one of the best engineering faculties in Portugal.

My engineering degree is one with more math and physics. This is because it’s key to get a solid grasp of math to understand electronics, telecommunications, control theory, and other areas of engineering.

Here’s a brief overview of some of the math and physics subjects I’ve learned:

• Partial Differential Equations (PDEs): These equations model real-world phenomena, from heat diffusion to the economy of a country.

• Harmonic Analysis (Fourier & Laplace): Integral transforms like the Fourier and Laplace transform allow us to understand problems in new domains.

• Complex Analysis: Extending calculus into the complex plane gives rise to powerful tools used in physics and engineering.

• Numerical Analysis: When analytical solutions are impossible or inefficient, numerical methods provide computer-based approximations. This is crucial for real-world applications.

• Control and Signal Theory: These areas show us how to design stable systems like rockets, trains, and robots.

• Physics: Courses in Classical Mechanics and Electromagnetism helped bridge theoretical math to physical laws

During my years of study, besides technical skills, I’ve developed a deeper understanding of how the world works and the structure of the field of mathematics. And I’ve started to find patterns in how math is a framework of interconnected logic.

In this article, we’ll explore:

• Simple Analogy: The Tree of Mathematics

• The Structure and History of Mathematics

• An Tree example: Foundations of Relativity by Albert Einstein

• The Biggest Paradox of Math, Discovered by Kurt Gödel

• What About Applied Math and Engineering?

• Code Examples – Analytical and Numerical Approaches

• The Impact of a Grand Unified Theory of Mathematics

• A Final Lesson From History

Simple Analogy: The Tree of Mathematics

Imagine math as a vast tree growing forever.

The roots of the tree are the foundations of mathematics: logic and set theory. From this foundation emerge the main basic fields of math: arithmetic, algebra, geometry, and analysis.

As the tree divides further and further into more branches, new, more complex subfields start to appear, like topology, abstract algebra, and complex analysis. Sometimes the branches are connected to each other.

And remember: this tree is always growing in many directions. From branches creating new branches to branches connecting to other branches. Little by little, it grows.

Throughout history, there have been times that, due to some big scientific discoveries, parts of the math tree started to grow very fast. Other times, decades and even centuries passed without many new branches. This is the case for imaginary numbers, for example.

And you might wonder: How many more branches and connections between them will keep appearing?

The Structure and History of Mathematics

The first mathematical ideas appeared independently across ancient civilizations. For example:

• India’s invention of zero

• Islamic algebraic advances

• Greek geometric rigor

Over time, many different great mathematicians created and shared them by writing and giving lectures.

Eventually, these new ideas were shared widely with new generations and these new generations created new math based on old math.

This is is how new branches are continuously born from previous branches of the tree of mathematics.

And this is why Isaac Newton wrote, in a letter to Robert Hooke in 1675:

If I have seen further, it is by standing on the shoulders of giants

He meant that by working from previous knowledge, he was able to create and (re)discover new ideas.

Yet, the real power of math lies in practicing it over and over and understanding it more and more deeply. As one of my professors once explained:

More important than knowing the theorems is knowing the ideas behind them and the history of how they were created.

Very often, to solve problems, it is necessary to think in terms of first principles and build from there. Math teaches exactly that. In this way, math is not just an academic subject. It is a language spoken by scientists and engineers around the globe.

By having it well preserved and shared, it is still possible to create new math from previous ideas. And it’s possible for the big tree to continue growing based on previous branches or nodes.

An Tree example: Foundations of Relativity by Albert Einstein

Albert Einstein created the general and special theories of relativity. These have big consequences nowadays:

• GPS and Global Communication

• Advancements in Satellite Telecommunications

• Space Exploration and Satellite Launches

But this was only possible through the unification of geometry with calculus, called differential geometry. The evolution of differential geometry happened over the centuries, thanks to many great mathematicians. Below are some of them, but this is not a complete list:

• Euclid (circa 300 BCE): Contributed to geometry, laying the groundwork for later mathematical systems

• Archimedes (circa 287–212 BCE): Pioneered the understanding of volume, surface area, and the principles of mechanics

• René Descartes (1596–1650): Developed Cartesian coordinates and analytical geometry

• Isaac Newton (1642–1727) & Gottfried Wilhelm Leibniz (1646–1716): Newton’s laws of motion and gravitation, alongside Leibniz’s development of calculus, formed the basis of classical mechanics that Einstein sought to extend and modify in his theory of relativity.

• Leonhard Euler (1707–1783): Contributed to the development of differential equations, which are essential in the mathematical foundations of physics.

• Gaspard Monge (1746–1818): The father of differential geometry and pioneer in descriptive geometry

• Carl Friedrich Gauss (1777–1855): Made groundbreaking advances in geometry, including the concept of curved surfaces.

• Bernhard Riemann (1826–1866): Introduced Riemannian geometry, a branch of differential geometry.

Once again, as Isaac Newton wrote, in a letter to Robert Hooke in 1675:

If I have seen further, it is by standing on the shoulders of giants.

Albert Einstein saw what no one else in his time saw, thanks to these great math giants and countless others.

The Biggest Paradox of Math, Discovered by Kurt Gödel

The biggest paradox in math, in my opinion, is what Kurt Gödel discovered. His early 20th century research revealed a limitation within this cycle.

This paradox – that is, his incompleteness theorems – shows that in any consistent formal system capable of expressing simple arithmetic, there will always be true mathematical statements that cannot be proven within the system itself.

This means that in ALL systems, there are limits to what you can actually prove as to what is true and false. For for mathematicians, this means that the tree will never be completed. There are truths that are beyond formal truths, and yet we still assume that they are true (albeit unproven).

This way, it proves that no matter how many mathematicians work in the field or how much AI is used to find new mathematics, there will always exist limitations. Some things are impossible to prove that are true, and we just know that they are due to approximation estimations and other non logical exact methods.

What About Applied Math and Engineering?

Applied math and engineering involves interpreting the same pure math ideas in real-world scenarios. Actually, in many cases, it is the combination of many math ideas. Let’s consider some examples:

Principal component analysis (PCA) is a widely used tool in data science. Yet, it is a mixture of linear algebra (in PCA, eigenvalues) with optimization (order eigenvalues that represent more data with less data) in order to make datasets shorter.

In machine learning, logistic regression is a mixture of calculus with statistics and probability.

In harmonic analysis, Laplace, Fourier, and Z-transforms are a way to see the same thing in a new domain to get new insights. In this case, integrals are used to make this mapping.

In deep learning, neural networks are just many matrices multiplying and updating themselves that adapt to model a dataset representing a system. This optimization of matrix values happens with activation functions, a gradient descent-based optimization method (tells how much values need to change), and backpropagation (applies those alterations to all matrix values).

I have actually written an article where I teach why activation functions are important if you want to check it out.

But the best example of this fusion of math with engineering is in control theory.

Control theory is the study of the architecture of systems. From trains to cars to airplanes, everything is based on control theory. It is everywhere in nearly all modern electronic devices. In electric circuits, control theory is also used heavily to guarantee circuit stability in the face of electric disturbances.

So as you can probably start to see, many of the tools we now have are just a mixture of many pure math ideas. Just many combinations and recipes of pure math ideas. In essence, applied math is the application of pure math as “ingredients“ in "recipes" to solve problems.

So, we’ve explored the structure and evolution of mathematics. Yet, it is important to see how these ideas can be applied in real life. Pure math makes the framework, and applied math applies that framework to solve problems. To understand this, we’ll examine two code examples that show how you can use math ideas as programming tools.

Code Examples – Analytical and Numerical Approaches

These code examples demonstrate a couple ways you can use Python to solve math equations.

In the first code example, we’ll solve the problem in the same way that kids in school solve math exercises: essentially, by hand with a pencil. Moving variables from left to right to find their values. In the second example, we’ll solve the problem using numerical analysis.

Example 1: Solve a Problem Analytically

When we solve math problems analytically, like we did in school, we are manipulating symbols to get exact values. Often there symbols are x, y and z. In Python, we can do this using the SymPy library:

from sympy import symbols, Eq, solve

x, y = symbols('x y')
eq1 = Eq(2*x + 3*y, 6)
eq2 = Eq(-x + y, 1)

solution = solve((eq1, eq2), (x, y))
print(solution)

Essentially, we are finding x and y based on this equation:

$$\begin{align*} 2x + 3y &= 6 \\ -x + y &= 1 \end{align*}$$

Which gives us the following result:

{x: 3/5, y: 8/5}

Or:

• x= 0.6

• y = 1.6

When we say that we’re solving this analytically, it means that we’re finding an exact mathematical solution using formulas or equations.

But many times, problems are harder and can be solved by adding symbols to the right or left of the equation.

Sometimes, there can be so many symbols and transformed versions of them, with things like derivatives and integrals, that it can become very hard to manage and takes a lot of time.

For this reason, there is an area of mathematics devoted to finding approximations of already created mathematical formulas called numerical analysis. It makes it faster to solve these problems. And this is the method we will explore next.

Example 2: Solve Numerically (Approximation)

We’ll now use SciPy to solve the same system with numerical methods:

import numpy as np
from scipy.linalg import solve

A = np.array([[3, 2, -1, 4, 5],
              [1, 1, 3, 2, -2],
              [4, -1, 2, 1, 0],
              [5, 3, -2, 1, 1],
              [2, -3, 1, 3, 4]])

b = np.array([12, 5, 7, 9, 10])

solution = solve(A, b)

print(solution)

In this code example, this line of code:

solution = solve(A, b)

Uses the solve method from the SciPy Python library:

from scipy.linalg import solve

It’s a method that helps you find the values of x in an equation A⋅x=b, where a is a square grid of numbers and b is a list of numbers. Which gives us the following:

[ 1.35022026 -0.79955947 -1.17180617  3.14317181 -0.83920705]

Now imagine, in this simple case, that a matrix like A could represent the traffic flow between cities or intersections, and b could represent the traffic entering or leaving each city.

By solving the system, it could help us determine the distribution of traffic between cities to meet desired traffic conditions.

Of course, these types of problems are far more complex in real life. But to understand and solve the big problems, you need to first understand the smaller problems.

And by the way, a system of equations is the same thing as a matrix. We just represent systems of equations as matrices to make the findings of properties and clarity easier to understand.

The thing is that by using matrices, it is easier to make calculations and to perform linear algebra math to check for characteristics of the matrix and understand it better.

In essence, a matrix represents a system of equations. Also, systems of equations can represent real life phenomena like the economy of a country or the weather.

If you want to know more, I wrote an entire article on numerical analysis that you can check out.

The Impact of a Grand Unified Theory of Mathematics

Despite the biggest paradox in mathematics, what would happen with a Grand Unified Theory of Mathematics?

Remember that such a theory tells us that there are things that are true that are impossible to formally prove, and we need to just accept it. But even with this assumption, it is still possible to unify all math.

This is what the Langland's program is trying to solve. A kind of attempt to interconnect the largest parts of the big tree of math to uncover new patterns in math.

With a Grand Unified Theory of Mathematics, we would be able to understand how every branch of the tree connects with the others and all the relationships between them.

What is the value of this big unification for society?

By studying history, we can find patterns. The unification of various fields has created many massive impacts on society, such as:

• In the 19th century, James Clerk Maxwell united the fields of electricity and magnetism with his famous Maxwell equations. This allowed the creation of radios and electric grids around the globe. In turn, it served as a foundation for all technological progress in the 20th and 21th century.

• In the 20th century, the unification of algebra with logic led to the rise of digital systems. In turn, digital systems gave the rise of processors and the evolution of computers to the modern laptop.

• Also in the 20th century, the unification of probability and communication led to information theory. This became the foundation for the internet. This unification was carried out by a great mathematician called Clause Shannon.

In the end, a Grand Unified Theory of Mathematics could be one of the biggest achievements in modern society.

It could lead to new discoveries in physics, such as in string theory or quantum gravity, where deep mathematical structures are needed to create new physics. In AI, it could help unify all machine learning models in a common architecture. This would help accelerate the development of new AI models. It could also open the door to new cryptographic methods and material science advances, revealing, with math, the deep patterns still not found in these fields.

Just as uniting electricity and magnetism led to modern technology, a unified math framework would lead to a wave of innovation.

A Final Lesson From History

From Greek geometry to AI, math has grown like a tree over centuries. By understanding its structure, it is possible to see its role in finding the patterns of our universe. I hope I was able to make you see math in this way.

In addition, we can conclude that the unification of scientific fields makes the foundations for the creation of new innovations to help society go forward. Many profound societal transformations only came to be thanks to abstract math ideas. When these are shared and refined, they become the hidden architecture of progress in society. Innovation begins when disconnected ideas are united, well-linked, and widely shared.

Find the full code here.

Dhawal shares the history of online courses and the Massive Open Online Course revolution of the early 2010s.

We also talk about his childhood growing up in India, and how his life changed one day when he won a computer from a Cartoon Network sweepstakes.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

You can listen to the podcast in Apple Podcasts, Spotify, or your favorite podcast app. You can also listen to the podcast below, right in your browser:

Dhawal took me out for traditional Mumbai food – vegetarian, and eaten with your hands. It was delicious.

Links we discuss during the conversation:

• Dhawal's article Here are 850+ Ivy League Courses You Can Take Right Now for Free
• Dhawal's article I uncovered 1700 Coursera Courses that Are Still Completely Free
• Dhawal on Twitter

Dhawal's 3 recommended Massive Open Online Courses:

1. Learning How to Learn: Powerful mental tools to help you master tough subjects
2. University of Alberta's Mountains 101 Course
3. Stanford's Data Structures and Algorithms Course

We'll go over the history of the language, why and where it is used, the compilation process, and some very basic programming concepts that are common in most popular programming languages.

This is not a complete guide to the language, but will rather give you a high level understanding of important C concepts and ideas as an absolute beginner to coding.

Each language has its own syntax and specific ways of doing things, but the concepts covered here are common and applied to all programming languages.

Having an understanding of how things work and these universal concepts can take you a long way in your coding journey. It makes learning a new technology easier in the long run.

This tutorial takes heavy inspiration from the material covered in the first couple of weeks of the course CS50: Introduction To Computer Science which I highly recommend to anyone wanting to dive deeper into computer science and programming no matter their level of experience.

Table of Contents

1. The History behind the origins of C - An Overview
2. Language Characteristics and why to consider learning C
3. Where Is C used?
4. Compilation process: Write-Compile-Run
5. Hello world
   1. Header files
   2. Main program
   3. Comments
   4. Output or printing to the console
6. Variables and assignment
   1. Assignment
   2. Declaring vs initialising a variable
   3. A couple rules for naming a variable
   4. The scope of a variable
      7. Data types
   5. Format codes
7. Operators
   1. Arithmetic operators
   2. Assignment operator
   3. Logical operators
   4. Comparison operators
      9. Functions
   5. Function arguments
   6. Function outputs
   7. Defining a method
   8. Calling a function
      10. Boolean Expressions
      11. Conditional Statements
      12. Loops
      13. While loops
      14. Do-While loops
8. Extra Reading

The History of the C Programming Language

The history of the C programming language is closely tied to the history of the development of the Unix Operating System.

If we look back to understand what led to the development of the operating system that changed the world of computing, we'll see the steps that led to the development of C.

Simply put, C was derived from the need to initially find and eventually create a language to apply on the Unix Operating system.

Project MAC and MULTICS

It all started in 1965 when the experimental project MAC was completed at MIT – the first system of its kind. This was the beginning of the MULTICS era. It used something called CTSS, or the Compatible Time Sharing System.

This was a key innovation at that time. Up to this point, we were in the early mainframe era, where massive, powerful, and extremely costly computers used to take up entire rooms.

To get tasks done, programmers would write code by hand. Then they'd punch a deck of paper tape cards that were encoded with the program written by hand.

They did this by handing the sheets of paper the program was written on to operators who used a key punch machine that would punch the card's holes and represent the data and instructions on the card.

Then they'd feed the punched cards to a punch card reader connected to the mainframe computer. It then converted the sequences in the cards holes to digital information. Simple tasks took a long time using this method and only one person could use each machine at a time.

The idea of time sharing changed everything. Instead of using cards, it attached multiple consoles (which at the time were mechanical terminals called teletypes) to a main computer. This allowed many people to use the same computer simultaneously.

Over 100 typewriter terminals spread around MIT's campus could be attached to one main big computer. This system supported up to 30 remote users at the same time, each using one of those terminals.

The operating system of the main computer multitasked and circled around the people who wanted to perform computing tasks from their connected terminals and gave a few seconds to each one.

It provided what seemed like a continuous service, appearing to be loading and running many programs simultaneously. But in reality it just went through each user's program very quickly. This gave the illusion that one person had the whole computer to themselves.

This system proved to be extremely efficient, effective, and productive, saving time and in the long run money, since those computers were extremely expensive.

Something that might have taken days to complete now took much less time. And this started enabling greater access to computing.

Following the success of the CTSS, MIT decided it was time to build upon this system and take the next step. This next step would be to create a more advanced time sharing system.

But they imagined a more ambitious endeavor than that: they wanted to build a system that would serve as a computing utility for programers that would be capable of supporting hundreds of users accessing the mainframe at the same time. And it would share of data and resources between them.

This would require more resources, so they joined forces with General Electric and Bell Labs.

This new project was named MULTICS, which stood for 'Multiplexed Information and Computing Service' and was implemented on one of General Electric's mainframes, the GE 635.

This team worked on MULTICS for a number of years. But in 1969 Bell Labs left the project because it was taking too long and was too expensive.

Bell Labs: The Innovation Hub

Bell Labs pulling out of the MULTICS project left some employees frustrated and looking for alternatives.

While working on MULTICS, the team created an unparalleled computing environment. They were used to working with time sharing systems and had seen their effectiveness. These programmers had a vast knowledge of operating systems, and the innovations from that project made them want to expand more.

A group led mainly by Ken Thompson and Dennis Ritchie wanted to use communal computing and create a file system that they could share. It would have the innovative characteristics they liked from MULTICS but they'd implement it in a simple, smaller, and less expensive way.

They shared their ideas and started to iterate.

_Ken Thompson and Dennis Ritchie, Image source from Wikipedia_

Bell Labs fostered an open and supportive environment that allowed creative expression and innovative ideas to bloom. It was research heavy, and they encouraged independent thinking problem solving to help them improve upon their initial solutions.

Through lots of discussion and experimentation they made the biggest breakthroughs and wrote history.

While still working on MULTICS, Ken Thompson had created a game called Space Travel. He initially wrote it on MULTICS, on the GE 635, but when Bell Labs pulled out he adapted the gamae to a Fortran program to run on the GECOS operating system that ran on the GE 635.

There were many problems with the game – it did not work as well on GECOS as it did on MULTICS and he needed a different and less expensive machine to run it on.

Ken Thompson faced rejection when asking for funding to create a different operating system, since Bell labs had pulled out from such a project already. But he did end up finding an old and little-used DEC PDP-7 minicomputer that he could try out – it was the only system available.

A DEC PDP-7, Image source from Wikipedia

He started to write his game on that simple system but was limited by the software on the computer. So while he was working on it, he ended up implementing the bare bones of the file system his team had been envisioning.

He started with a hierarchical file system, a command line interpreter, and other utility programs. Within a month he had created an operating system with an assembler, editor, and shell. They were smaller and simpler features of MULTICS. This operating system was the first version of Unix.

The Early Days of Unix with Assembly language

At the beginning of the project, Ken Thompson could not program on the DEC PDP-7 computer. DEC PDP-7 programs had to be compiled and translated on the more powerful GE 635 mainframe and then the output was physically transferred to the PDP-7 by paper tape.

The DEC PDP-7 had very little memory, just 8KB. To deal with this restriction, the filesystem, the first version of the Unix kernel, and practically everything else in the project were coded in Assembly. Using Assembly allowed Thompson to directly manipulate and control each part of the memory on that computer.

Assembly language is a low level programming language which uses symbolic code and is close to the machine's native language, binary. The instructions in the code and each statement in the language closely corresponds to machine instructions specific to the computer's architecture.

It's machine dependent and machine specific, meaning one set of instructions has very different results from one machine to another. Programs written in Assembly language are written for a specific type of processor – so a program written in Assembly will not work on a variety of processors.

It was common to write operating systems using Assembly language back then. And when they first started working on Unix, they did not have portability in mind.

They didn't care if the operating system worked on different machine systems and architectures. That was a thought that came later. Their main priority was the efficiency of the software.

While working on MULTICS, they used high level programming languages, like PL/I in the beginning and later BCPL. Programmers had gotten used to using high level languages for writing operating system kind of software, utilities, and tools because of the advantages they offered (they were relatively easy to use and understand).

When using a higher level programming language, there is an abstraction between the computer's architecture and various obscure details. This means that it is above the level of the machine and there is no direct manipulation of the hardware's memory.

High level languages are easier to read, learn, understand, and maintain which makes them an easier choice when working on a team. Commands have an English like syntax, and terms and instructions look more familiar and human-friendly compared to the symbolic format of Assembly.

Using high level languages also means writing less code to achieve something, whereas assembly programs were extremely long.

Thompson wanted to use a higher level language for Unix from the very start, but was limited by the DEC PDP-7.

As the project progressed and as more people started working working on it, using Assembly was not ideal. Thompson decided that Unix needed a high level system programming language.

In 1970 they managed to get funding for the bigger and more powerful DEC PDP-11 that had substantially more memory.

With a fast, structured, and more efficient high level programming language that could replace Assembly, everyone could understand the code and compilers could be made available to different machines.

They started exploring different languages for writing system software that they could use to implement Unix.

From B to C: The Need for a New Language

The aim was to create utilities – programs that add functionality – to run on Unix. Thompson initially attempted to create a FORTRAN compiler but then turned to a language he used before, BCPL (Basic Combined Programming Language).

BCPL was designed and developed in the late 1960's by Martin Richards. Its main purpose was for writing compilers and system software.

This language was slow and had many restrictions, so when Thompson started using it in 1970 for the Unix project on the DEC PDP-7, he made adjustments and modifications and ended up writing his own language, called B.

B had many of the features of BCPL but it was a smaller language, with a less verbose syntax and simpler style. It was still slow and not powerful enough to support Unix utilities, however, and couldn't take advantage of the powerful features of the PDP-11.

Dennis Ritchie decided to improve upon these two previous languages, BCPL and B. He took features and characteristics from each and added additional concepts. He created a more powerful language – C – just as powerful and efficient as Assembly. This new language overcame the limitations of its predecessors and could use the power of the machine in an effective way.

So in 1972 C was born, and the first C compiler was written and implemented for the first time on the DEC PDP-11 machine.

_The famous picture of Thompson and Ritchie working on a PDP-11, Image source Wikipedia_

The C Programming Language

In 1973 Dennis Ritchie rewrote the Unix source code and most Unix programs and applications using the C programming language. This made it the standard implementation language of the operating system.

He reimplemented the Unix kernel in C, and almost all of the operating system (well over 90%) is written in this high level language. It mixes both high level readability features and the low level functionality, making it the perfect choice for writing an operating system.

Towards the late 1970's, C's popularity started to rise and the language started getting more widespread support and use. Up until that point, C was still only available for Unix systems and compilers were not available outside of Bell labs.

This increase in popularity came from not only the power C gave to the machine but also to the programmer. It also helped that the Unix operating system was gaining the same popularity at an even faster rate.

Unix stood out from what came before because of its portability and its ability to run on a variety of different machines, systems, and environments.

C made that portability possible and since it was the language of the Unix system, it gained more notariety – so more and more programmers wanted to try it out.

In 1978 Brian Kernighan and Dennis Ritchie co-wrote and published the first edition of 'the C programming language' book, also known in the programming community as 'K&R'. For many years this text was the go-to for C language description, definition, and reference.

[Front page cover of the book,image source Wikipedia](https://en.wikipedia.org/wiki/C(programminglanguage)#History)

In the 1980's, C's popularity skyrocketed as different compilers were created and comercialized. Many groups and organisations that were not involved in C's design started making compilers for every operating system and computer architecture structure. C was now available on all platforms.

As these organisations created compilers of their own, they started to change characteristics of the language to adapt to each platform the compiler was being written for.

There were various versions of C that had slight differences between them. While writing the compilers, these groups came up with their own interpretations of some aspects of the language, which were based on the first edition of the book 'C programming language'.

With all the iterations and adjustments, though, this book no longer described the language as it was, and the changes to the language started to cause problems.

The world needed a common version of C, a standard for the language.

The C Standard

To make sure there was a standard, machine independent definition of the language, ANSI (the American National Standards Institute) formed a committee in 1983. This committee was named the X3J11 committee, and their mission was to provide a clear, comprehensive definition and standardization of C.

After a few years, in 1989, the committee's work was done and made official. They defined a commercial standard for the language. That version of the language is known as 'ANSI C' or C89.

C was used all around the world, so a year later in 1990 the standard was approved and adopted by ISO, the International Standards Organization. The first version, C90, was called ISO/IEC 9899:1990.

Since then, many revisions to the language have taken place.

The second version of the standard, C99, was published in 1999 called ISO/IEC 9899:1999 and introduced new language additional features. The third version, C11, was published in 2011. The most recent version is the forth, C17, and is called ISO/IEC 9899:2018.

The Continuation of C

C forged a path for the creation of many different programming languages. Many of the modern high level programming languages that we use and love today are based on C.

Many of the languages created after C wanted to solve problems that C couldn't, or overcome some of the issues that limit C. For example, the most popular child of C is its Object Oriented extension C++ – but Go, Java, and JavaScript were also inspired by C.

C Language Characteristics and Why You Should Consider Learning C

C is an old language, but it still remains popular to this day, even after all these years.

It owes its popularity to the rise and success of Unix, but nowadays it has gone far beyond just being the 'native' language of Unix. It now powers most, if not all, of the world's servers and systems.

Programming languages are tools we use to solve specific computing problems that affect us on a large scale.

You don't need to know C to create web pages and web applications. But it comes in handy when you want to write an operating system, a program that controls other programs, or a programming utility for kernel development, or when you want to program embedded devices or any systems application. C excells at all these tasks. So let's look at some reasons to learn C.

It helps you understand how your computer works

Despite the fact that C is a general purpose programming language, it is mainly used to interact with low level machine functions. Besides the practical reasons behind learning the language, knowing C can help you understand how the computer actually works, what is happening underneath the hood, and how programs actually run and execute on machines.

Since C is considered the base of other programming languages, if you can learn the concepts used in this language it will be easier to understand other languages too later on.

Writing C code lets us understand the hidden processes happening in our machines. It allows us to get closer to the underlying hardware of the computer without messing with Assembly language. It also lets us get a handle on a multitude of low level tasks while staying readable like high level languages.

C is fast and efficient

At the same time, we don't lose the functionality, efficiency, and low level control of how code executes that Assembly provides.

Rememeber that each processor in every device's hardware has its own Assembly code that is unique to that processor. It's not at all compatible with any other processor on any other device.

Using C gives us a faster, easier, and overall less cumbersome approach to interacting with the computer at its lowest level. In fact, it has a mixture of both high and low level features. And it helps us get the job done without the hassle and fuss of long incomprehensible Assembly code.

So, C is as close as you can get to the computer's underlying hardware and is a great replacement for Assembly (the old standard for writing operating systems) when you're working with and implementing system software.

C is powerful and flexible

This close proximity to the hardware means that C code is written explicitly and precisely. It gives you a clear picture and mental model of how your code is interacting with the computer.

C does not hide the complexity with which a machine operates. It gives you a lot of power and flexibility, like the ability to manually allocate, manipulate, and write directly to memory.

The programmer does a lot of the heavy work and the language lets you manage and structure memory in an efficient way for the machine delivering high performance, optimisation, and speed. C lets the programmer do what needs to get done.

C is portable, performant, and machine-independent

C is also highly portabile and machine independent. Even though it is close to the machine and has access to its low level functions, it has enough abstraction from these parts to make code portability possible.

As Assembly instructions are machine specific, programs are not portable. One program written on one machine would have to be re-written to run on another. And that is hard to maintain for every computer architecture.

C is universal and programs written in it can be compiled and run across many platforms, architectures, and a variety of machines without losing any performance. This makes C a great choice for creating systems and programs where performance really matters.

C inspired the creation of many other programming languages

Many languages that are commonly used today, like Python, Ruby, PHP and Java, were inspired by C. These modern languages rely on C to work and be efficient. Also, their libraries, compilers, and interpreters are built in C.

These languages hide most of the details about how programs actually work underneath the hood. Using these languages, you don't have to deal with memory allocation and bits and bytes since there are more levels of abstraction. And you don't need this level of granular control with higher level applications where interaction with memory is error-prone.

But when you're implementing part of an operating system or embedded device, knowing those lower-level details and direct handling can help you write cleaner code.

C is a fairly compact language

Although C can be quite cryptic and hard to learn for beginners, it is actually a fairly small and compact language with a minimal set of keywords, syntax, and built-in functions. So you can expect to learn and use all of the features of the language when exploring how it works.

Even if you're not interested in learning how to program an operating system or a systems application, knowing C basics and how it interacts with the computer will give you a good foundation of computer science concepts and principals.

Also, understanding how memory works and is laid out is a fundamental programming concept. So understanding how the computer behaves on a deeper level and the processes that are happening can really help you learn and work with any other language.

Where Is C used?

There is a lot of C code in the devices, products, and tools that billions of us use in our everyday lives. This code powers everything from the world's supercomputers to the smallest gadgets.

C code makes embedded systems and smart devices of all kinds work. Some examples are household appliances like fridges, TVs, coffee makers, DVD players, and digital cameras.

Your fitness tracker and smart watch? Powered by C. The GPS tracking system in your car, and even traffic light controllers? You guessed it – C. And there are many examples of embedded systems used in the industrial, medical, robotics, and automobile industries that run on C code.

Another area where C is widely used is Operating Systems and kernel development. Besides Unix, for which the language was created, other major and popular Operating Systems are coded to some extent in C.

The Microsoft Windows kernel is scripted mostly in C, and so is the Linux kernel. Most supercomputers are powered by Linux, and so are most Internet servers. This means that C powers a large section of the Internet.

Linux also powers Android devices, so C code not only makes supercomputers and personal computers work, but smartphones too. Even OSX is coded to some extent in C, which makes Mac computers run on C, too.

C is also popular for developing desktop applications and GUIs (Graphical User Interfaces). Most Abode Applications we use for video and photo editing and graphic design (like Photoshop, Adobe illustrator, and Adobe Premiere) are coded with C or its successor, C++.

Compilers, interpreters, and assemblers for a variety of languages are designed and built with C – in fact these are some of the most common usages of the language.

Many browsers and their extensions are built with C, like Google Chromium and the Google file system. Developers also use C often in database design (MySql and Oracle are two of the most popular database systems built in C), and it powers advanced graphics in many computer games.

From this general overview, we can see that C and it's derivative C++ run a large part of the internet and the world at large. Many of the devices and technologies we use in our daily lives are written in or depend on C.

C Compilation Process: Write-Compile-Run

What is a program in C?

A computer program written in C is a human readable and ordered set of instructions that a computer executes. It aims to provide a solution to a specific computing problem and tell the computer to perform a certain task with a sequence of instructions that it needs to follow.

Essentially all programs are just plain text files stored on your computer’s hard drive that use a special syntax which is defined by the programming language you're using.

Each language has its own rules that dictate what you can write and what's considered valid, and what is not.

A program has keywords, which are specific words that are reserved and are part of the language. It also has literal pieces of data like strings and numbers. And it has words that follow the language’s rules, which we define and introduce to the language that don’t already exist (like variables or methods).

What is a compiler?

Programs are written by us and for us. They are meant to be understood by humans.

When we write programs in human readable form, we can understand them – but the computer may not be able to. Computers don’t directly understand programming languages, they only understand binary. So programs need to be translated into this other form so the computer can actually understand our program's instructions.

Programs in high level languages can be either compiled or interpreted. They use special pieces of software called compilers and interpreters, respectively.

What's the difference between an compiler and an interpreter?

Both compilers and interpreters are programs, but they're far more complex ones, and they act as translators. They take a program that's written in a human readable form and turn it into something that computers can make sense of. And they make it possible to run and execute programs on different computer systems.

Compiled programs are first converted into machine-readable form which means they are translated into machine code before they run. Machine code is a numerical language – binary instructions composed of sequences of 0s and 1s.

This compliation produces an executable program, that is a file containing the code in the machine language that the CPU (Central Processing Unit) will be able to read, understand, and execute directly.

After this, the program can run and the computer does what the program tells it to do. Compiled programs have a stronger correspondence with the underlying hardware and can more easily manipulate the computer's CPU and memory.

Interpreted programs, on the other hand, are not directly executed by the machine nor do they need to be translated into a machine language program. Instead, they use an interpreter that automatically and directly translates and executes each statement and instruction in the code line by line during run time.

C is a compiled programming language. This means that it uses a compiler to analyse the source code written in C and then turns it into a binary file that the computer's hardware can directly execute. This will be specific for each particular machine.

How to use the GCC Compiler with examples

Unix and Unix-like systems already have a C compiler built in and installed. This means that Linux and MacOS have a popular compiler built in, called the GCC Compiler (or GNU Compiler Collection).

In the rest of this section we'll see examples using this compiler and I've based these examples on a Unix or Unix-like system. So if you have a Windows system, make sure to enable the Windows Subsystem for Linux.

First, make sure you have the GCC compiler installed. You can check by opening your terminal and typing gcc --version in the prompt which is typically after the $ character.

If you're using MacOS and have not installed the command line developer tools, you will get a dialog box pop up asking you to install them – so if you see that, go ahead and do so.

Once you have those installed, open a new terminal session and re-type the gcc --version command. If you have already installed the command line tools, you should get the output below:

The term compiling alone is an abstraction and simplification, though, since in reality there are many steps happening behind the scenes. These are the finer lower level details that happen between us writing, compiling, and then running our C program. Most even happen automatically, without us even realising it.

How to write C source code

In order to develop C programs, we first need to have some type of text editor. A text editor is a program we can use to write our code (called our source code) in a text file.

For this you can use a command-line text editor like nano or Vim if you are comfortable with those.

You can also use an IDE (Integrated Development Environment), or text editor with IDE-like features (an integrated terminal, the ability to write, debug, run and execute our programs all in one place without leaving the editor, and much more).

One editor with these capabilities is Visual Studio Code, using the C/C++ extension. Throughout the rest of this tutorial we'll use VSCode.

Back in your terminal, go ahead and type the commands below to create a file where our C code will live.

`cd` # Takes us to our home directory,if not there already
`mkdir cprogram` # Creates a directory named cprogram 
`cd cprogram` #navigates us into the cprogram directory we just created
`touch hello.c` #creates a file named hello
`code .` #opens VSCODE  in the current directory

So we have just created a plain text file, hello.c. This file will have code written in the C language meaning it will be a C program. This is indicated by the .c file extension which is a convention.

Inside it we can write any C program we like, starting from a very basic one like a program that outputs 'hello world' to the screen.

In order to see what our code does, we have to run the program we have just written. Before running it, though, we have to first compile it by typing some commands in the terminal.

We can continue using the command line on our computer or we can use the integrated terminal in VSCode (by holding the control ~ keys at the same time a new terminal window opens).

So far we can see on the left panel that there is only one file in our cprogram directory, hello.c, which contains our C code.

The term 'compiling our C code' doesn't just happen in one step. It also involves some smaller actions that occur automatically for us.

As a reminder, when we refer to compiling, we typically mean that the compiler takes our source code as input (the code we wrote in C which has English like syntax), and translates it to produce machine code statements as output.

This machine code corresponds directly to our source code instructions, but it's written in a way the CPU can understand so it can carry out the instructions and execute them.

How C source code gets transformed into binary code

This is the general idea – but there are 4 smaller steps involved that happen in between. When we compile our code we are actually preprocessing, compiling, assembling, and linking it.

These steps start happening when we type the command gcc hello.c in the terminal which is the name of the compiler and the source code file, respectively.

If we wanted, we could alternate and customise that command by typing a more specific one like gcc -o hello hello.c, where:

• -o stands for 'output this file'
• hello is the name we ourselves specify for the executable program file we want to output that will be created, and
• hello.c is the file the gcc compiler will take as input (which is the file where our source code lives and we want to compile).

Preprocessing in C

Another program that is part of the compiler conducts this first step – the preprocessor. The preprocessor does many things – for example, it acts as a ‘find and replace tool’ as it scans through our source code looking for special statements and searches for lines starting with a #.

Lines starting with a # ,like #include, are called preprocessor directives. Any line starting with a # indicates to the preprocessor that it must do something. In particular, it tells that it should substitute that line with something else automatically. We don't see this process, but it's happening behind the scenes.

For example, when the preprocessor finds the line #include <stdio.h> in our hello world program from earlier, the #include literally tells the preprocessor to include, by copying and pasting, all the code from that header file (which is an external library, stdio.h) in the place of that statement in our own source code. So it replaces the #include <stdio.h> line with the actual contents of the stdio.h file.

Inside the <stdio.h> library there are function prototypes and definitions or hints. This way all the functions are defined so the computer recognizes them during compilation time, and we can use them in our program.

For example, the function printf(); is defined as int printf(const char *format,…); inside <stdio.h>. The same steps happen for other header files, that is files with a .h extension.

During the preprocessing step, our comments in our code are also removed and macros are expanded and replaced with their values. A macro is a fragment of code which has been given a name.

At this stage if there are no errors in our code, there should be no output in the terminal, which is a good sign.

We see no output, but a new file has been created with a .i extension which is still C source code. This file includes the output from the preprocessing, so it is called preprocessed source code. In this case a new file, hello.i, is generated but it won't be visible in our editor.

If we run the command gcc -E hello.c:

We will be able to see all the contents of this file (which is a lot) and the ending looks something like this:

If there are any mistakes with the correctness of our code or we're not following the semantics of the language, we'll see some errors and the compilation will end. We would have to correct the mistakes and start the process from the beginning.

Compiling in C

After the preprocessing step which produces preprocessed C source code, next we have to compile the code. This involves taking the code that is still source code and changing it into another intermediate form. We use a compiler for this step.

To review, a compiler is a program which takes as input the source code and translates it into something closer to the native language of computers.

When we refer to compiling we can either mean the entire process of translating source code to object code (machine code) or just a specific step in the whole compilation process.

The step we're discussing now is when compiling converts every statement of the preprocessed C source code program to a more computer friendly language. This language is closer to binary which the computer can actually directly understand.

This intermediate language is assembly code, a low level programming language used to control the CPU and manipulate it to perform specific tasks and get close access to the computer's memory. Remember assembly code from the history section?

Every CPU – the brains of the computer – has its own set of instructions. Assembly code uses specific statements and commands that directly correlate to those instructions and low level operations that a CPU performs and carries out.

So in this step of the compilation process, each statement in the preprocessed C source code in the file hello.i is translated by the compiler to the equivalent statement in assembly language at a lower level.

The output of this action creates a file ending in .s (so hello.s behind the scenes) that contains instructions in assembly.

By typing the command gcc -S hello.c we can view the contents and the somewhat incomprehensible assembly commands of the hello.s file that the compiler created (but that was not visible to us when we typed gcc hello.c alone).

If we look closely we'll see a couple familiar keywords and statements used in our C source code like main and printf:

Assembling in C

Assembling means taking the hello.s file containing assembly code statements as input and, with the help of another program that is executed automatically in the compilation process, assembling it to machine code instructions. This means it will have as output actual 0s and 1s, or binary format statements.

This step also happens behind the scenes, and it results in the final language the instructions in our source code are translated to. And now the computer can finally understand those instructions.

Each of the commands we wrote in our C source code were transformed to assembly language statements and finally into the equivalent binary instructions. All this happened just with the command gcc. Whew!

The code we wrote is now called object code, which a specific computer's CPU can understand. The language is incomprehensible to us humans.

People used to code in machine language, but it was a very tedious process. Any symbols that are non-machine code symbols (that is, anything that's not 0s and 1s) are hard to make sense of. Coding in such a language directly is extremely error-prone.

At this stage, another file is created with a .o extension (for object) – so in our case it'll be hello.o.

We can see the actual contents of the object file containing the machine level instructions with the command gcc -c hello.c. If we do this, we'll see the not human readable contents of hello.o:

Linking in C

In the images above, you might have noticed an a.out file in our directory.

This is the default step and file that gets created when we type the compiler command and our filename, gcc hello.c in our case.

If we had used the command gcc -o hello hello.c mentioned earlier, we would have seen a custom named hello executable program in place of a.out.

The a.out stands for assembly output. If we type ls in the terminal to list the files in our directory, we see that a.out even looks different from the rest:

Linking is the final stage of the compilation process where the final binary file hello.o is linked with all the other object code in our project.

So if there are other files containing C source code (like files included in our program that implement C libraries which are already processed and compiled, or another file we have written named, for example, filename.cbesides hello.c), this is when the object file filename.o will be combined with hello.o and the other object codes, linking them all together.

This forms one big executable file with the combined machine code, a.out or hello, which represents our program.

Since we're finally done compiling, the program is in its final form. And now we can execute and run the file on our machine by typing ./a.out. This means 'run the a.out file that is in the current directory', since ./ represents the folder we are in. We then see the output of our program in the terminal:

Whenever we make changes to our source code file, we have to repeat the process of compiling from the beginning in order to see the changes when we run the code again.

How to Write Hello World in C

A hello world program is a very simple one, but it's a tradition that also acts as a test message when you're first starting to learn how to code in a new programming language.

If you execute your "Hello World" program successfully, this lets you know that your system is correctly configured.

_'Hello world' devised by Brian Kernighan from Artsy's Algorythm Auction based on a 1974 Bell Laboratories internal memorandum, "Programming in C: A Tutorial," which contains the first known version. It was reprinted in the popular 1978 book, The C Programming Language. Image and description source from Wikipedia_

A 'hello world' program contains the basic syntax for the language and we can break it down into smaller parts:

#include<stdio.h>

int main(void)
{
    // print hello world to the screen
    printf("Hello world\n");
}

Header files in C

Header files are external libraries. This means they are a set of code already written by some developers for other developers to use.

They provide features that are not included at the core of the C language. By adding header files to our code, we in return get additional functionality that we can use in our programs.

Header files like include <stdio.h> end in the extension .h. In particular, a header file like stdio.h comes already built into the compiler.

The line include <stdio.h> is an instruction for the pre-written functions in the stdio.h library file which tells the computer to access and include them in our program.

stdio.h gives us the functionality standard input and standard output, which means we'll be able to get input and output from the user. We therefore get to use input/output functions like printf.

If you don't include the stdio.h file at the top of your code, the computer will not understand what the printf function is.

The main program in C

Here's the code:

int main(void)
{
}

This is the main starting function of a C program. The curly braces ({}) are the body which wraps all the code that should be in our program.

This line acts as a boilerplate and starting point for all C programs. It lets the computer know where to begin reading the code when it executes our programs.

Comments in C

Whatever we write after the // will not affect how our code runs and the computer will not take it into account during compilation and execution time.

Those two lines indicate that you're adding comments, which are notes to our future selves and to our coworkers. Comments can help us remember and remind others what a certain line of code does or why we wrote that code in the first place. It also reminds us what exactly is the purpose of that code when we come back to it the next day of even months later.

Output or printing to the console in C

printf("Hello world/n"); prints the phrase 'Hello world' to the console. We use printf when we want to say something and to see the output on the screen. The characters we want to output need to be surrounded by double quotes "" and parentheses ().

The /n is an escape character, which means that it creates a newline and tells the cursor to move to the next line when it sees it.

The ; indicates the end of of sentence and the end of that line of code.

Variables in C

Here's how we define a variable in C:

A data item that may take on more than one value during the runtime of a program.

In the simplest terms, you can think of variables as a named box. A box that acts as a storage place and location for holding different information that can vary in content.

Each box has a unique name which acts like a label put on the outside that is a unique identifier, and the information/content lives on the inside. The content is the variable's value.

Variables hold and point to a value, to some useful data. They act as a reference or abstraction to literal data. That data is stored in the computer's memory, and takes up an certain amount of space. It lives there so we can retrieve it later and use it in our programs when we need to.

As the name suggests, what variables point to can vary. They are able to take different values over time as information changes during the life of the program.

Variable Assignment in C

The process of naming a variable is called assignment. You set a specific value that is on the right, to a specific variable name that is on the left. You use the = or the assignment operator to do this.

As I mentioned, you can change a variable's value, so you can assign and reassign variables. When you reassign a value, the new value points to the variable name. So the value can be a new one, but the variable name stays the same.

How to declare vs initialise a variable in C

The C programming language is a strongly statically typed language, unlike many other modern programming languages.

In statically typed languages, you need to explicitly declare your variables to be of a certain data type. That way the compiler knows during compilation time if the variable is able to perform the actions it was set out and requested to do.

In dynamically typed languages, a variable can change between different data types without the need to explicitly define that data type.

So, when declaring a new variable in the C language, you need to define and specify what type it is, and what type of data its value holds.

A variable's type is the type of the value it holds. This lets the program and later the compiler know what kind of information it's storing.

To declare a variable, you specify the data type, and give a name to the variable. An optional step is to set an initial value. Do not forget the semicolon at the end, which ends the statement!

#include <stdio.h>

int main(void)
{
  int n = 27;
  // int is the data type
  // n is the name 
  // n is capable of holding integer values
  // positive/negative whole numbers or 0
  // = is the assignment operator
  // 27 is the value
}

What is the difference between initialising and declaring a variable?

In summary:

int n; // declaration, create a variable called n capable of holding integer values
int n = 27; // initialisation, creating a variable called n and assigning a value, storing a number in that variable

int n; is declaring a variable. Declaring means we define a name for the variable and specify its type.

We don't necessarily need to specify a value for the variable just yet. This is enough, as declaring a variable tells the computer we want a variable to exist and we need to allocate some space in memory for it. The value can and will be stored at a later time.

When we do assign the variable a value later, there is no need to specify the data type again. We can also declare multiple variables at once.

int name, age;

If we declare a variable and assign it a value at once, this is called initialising the variable.

int n = 27; is initialising the variable. It refers to assigning an initial value which we can change later.

If the new value is the same data type, we don't need to include the data type, just the new value. If the data type is different, we will get an error.

#include<stdio.h>

int main(void)
{
  int age = 27;
  age = 37;
  // the new value of age is 37
}

Rules for naming variables in C

• Variable names must begin either with a letter or an underscore, for example age and _age are valid.
• A variable name can contain letters (uppercase or lowercase), numbers, or an underscore.
• There can be no other special symbols besides an underscore.
• Variable names are case sensitive, for example age is different from Age.

The scope of a variable in C

The scope of a variable refers to where the variable can be referenced and accessed from. It is essentially where the variable lives and is valid and how visible it is to the rest of the program.

Local scope

If a variable is declared within a set of culry braces, {}, like for example a specific function, that will be its scope and we can't access it and use it outside those braces in the rest of the program. The rest of the program won't know it exists.

Therefore it is not a good idea to declare variables that way since their scope and use is so limited which can lead to errors. This scope is called local scope.

Global scope

If variables are declared outside of functions, they have global scope. Having a global scope means they are visible within the whole program and can be accessed from anywhere.

But keep in mind that it can be difficult to keep track of them. Also, any changes we make to them along the way can get confusing since they can happen in any part and location of the program.

Data Types in C

Data types specify in what form we can represent and store information in our C programs. They let us know how that information will be used and what operations can be performed on it.

Data types also determine what type of data our variables can hold, as each variable in C needs to declare what data type it represents.

There are 6 data types built into the language. But you can convert between different types which makes it not as strongly typed.

Each of the data types requires a different allocation of memory and each data type can have different ranges up to which they can store values.

Adding keywords in front of a type name modifies and makes changes to the type. These keywords can be either unsigned or signed.

An unsigned keyword means that the type can only be positive and not negative, so the range of numbers start from 0. A signed keyword lets you make a number negative or positive.

Let's look at these data types in more detail.

The char data type in C

The most basic data type in C is char. You use it to store a single character such as letters of the ASCII chart like 'a', 'Z', or '!". (Notice how I used single quotation marks surrounding the single character – you can't use double quotes in this case.)

char also lets you store numbers ranging from [-128 to 127] and in both cases uses 1 byte of memory.

An unsigned char can take a range of numbers form [0-255]

The int data type in C

int is a an integer, a whole number, that can hold a positive or negative value or 0 but that has no decimal.

It is a value up to a certain number of bits. When you declare an int, it the computer allocates 4 bytes of memory for it. More specifically it uses at least 2 bytes but usually 4. 4 bytes of memory means it allocates 32 bits (since 1 byte = 8 bits). So an int has 2³² possible values – more than 4 billion possible integers.

The range is of a -2³¹ to 2³¹-1,specifically from [-2,147,483,648 to 2,147,483,647].

• An unsigned int has still the same size as an int (4 bytes) but that doesn't include the negative numbers in the range of possible values. So the range is from 0 to 2³²-1, more specifically [0 to 4,294,969,295]
• A short int has smaller values than an int and allocates 2 bytes of memory. It allows for numbers in a range of [-32,768 to 32,767]
• An unsigned short int uses again 2 bytes of memory and has a range of numbers from [0 to 65,535]
• A long int is for when we need to use a larger number. It uses at least 4 bytes of memory, but usually 8 bytes with values from [-2,147,483,648 to 2,147,483,647]
• An unsigned long int has at least 4 bytes of memory with a range from [0 to 4,294,967,295]
• A long long int is an integer with more bits that's able to count to higher and larger numbers compared to ints and long ints. They use 8 bytes instead of 4 and so use 64 bits. This allows for a range from -2⁶³ to 2⁶³-1 ,so for numbers from [-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807]
• An unsigned long long uses 8 bytes and has a range of numbers from [0 to 18,446,744,073,709,551,615]

The float data type in C

Floats are a floating point value which is a number with a decimal (also called a real number), with single precision. It allocates 4 bytes of memory.

The double data type in C

A double is a floating point value which has bigger values than that of a float. It can hold more memory – 8 bytes – compared to a float, and is double precision.

• A long double is the largest size compared to floats and doubles, holding at least 10 bytes of memory, but can even hold up to 12 or 16 bytes.

And lastly, the void type essentially means nothing or no value.

Format Codes in C

Format codes or format specifiers are used for input and output in C.

These are a way to tell the compiler what type of data it takes in as input with a variable, and what type of data it produces as output when using the printf() function. The f in printf() stands for formated.

They act as a format code placeholder and substitute for variables. They let the compiler know in advance what type they are when the value of the standard output (that is, what we want to print) is not already known.

The syntax we use is % format specifier for data type:

#include<stdio.h>
int main(void)
{
    int age = 27;
    printf("My age is %i/n", age)
    // prints 27
// age is the variable we want to use 
// %i is the format specifier,a placeholder for an integer value
// we separate each argument with a comma
// in the output %i  is replaced with the value of age
}

There are different format specifiers for each data type we discussed earlier. Here are some of them:

Operators in C

Arithmetic operators in C

Arithmetic operators are mathematical operators that perform mathematical functions on numbers. Operations can include addition, subtraction, multiplication, and division.

The most commonly used operators are:

• + for addition
• - for subtraction
• * for multiplication
• / for division
• % for modulo division (calculating the remainder of the division)

Assignment operator in C

The assignment operator, =, assigns a value to a variable. It 'puts' a value into a variable.

In other words, it sets whatever is on the right side of the = to be the value of the variable on the left side of the =.

There are specific assignment operators for updating a variable by modifying the value.

In C, there are various ways we can update the values of variables. For example, if we want to increment the variable by 1 there are three possible ways to do so.

It is worth mentioning first that incrementing means to take the existing value of a variable, whatever value is on the right, and add 1 to it. The new value is then stored back to the variable and automatically updated.

The simplest way to increment or update is to have a variable called x with an initial value of 5, so:

x=5.

To add 1 to the variable x, we do x = x + 1 which means x = 5 + 1.

The new value of x is now 6, x=6.

There is a shorthand for this operation, using a special syntax that increments variables.

Instead of writing x = x +1 we can write x += 1.

An even shorter way is to use the increment operator, which looks like variable_name ++, so in our case x++.

The same goes for decreasing, that is decrementing, a variable by 1.

The three ways to do so are:

x = x-1, x -= 1, x -- (using the decrement operator) respectively.

Those are the ways to increment and decrement a variable by 1 in C. We are able to update a variable by taking its value and adding, subtracting, multiplying, and dividing that value by any other number and setting the result of that operation as the new value. Those operations would be +=, -=, *=, and /= respectively.

So x = x * 5 or the shorthand x *= 5 will take the value of the variable x and multiply it by 5 and store it back to x.

Logical Operators in C

We use logical operators to make decisions in C. The result of an operation can be either true or false.

There is the logical AND operator, &&. Operands on both the left and right sides of && need to be true for the condition to be true.

There is also the logical OR operator, ||. At least one or both of the operands on the right and left sides of || need to be true for the condition to be true.

Lastly, there is the logical NOT. This inverts the value of the operand. If an operand is true, then the NOT operator makes the condition false and vice versa.

Comparison operators in C

Comparison operators are:

• Greater than >
• Greater than or equal to >=
• Less than <
• Less than or equal to =<

There is also an equality comparisson operator, ==. Don't confuse this with =, the assignment operator.

We use the == to compare two values and test to see if they are equal or not. This operator asks the question 'Are these two equal?', whereas = assigns a value to a variable.

When using the equality comparisson operator and asking the above question, there is always a return value that can either be true or false, otherwsie knokn as a Boolean value in the context of computer programming.

Lastly, there is the inequality operator, !=, that we use to test whether two values are NOT equal.

Functions in C

Functions are verbs, that is, small actions. They do something. They perform a particular, specific task.

They encapsulate a piece of behaviour that is meant to be used again and again. The purpose of functions is to have that behaviour written out just once somewhere so you can reuse it whenever you need to, at different times and in different places throughout a program. This makes your code simpler and better organised.

Functions exist to perform one task, serve a particular purpose, and be reused. And they can take in inputs and produce outputs.

Function arguments in C

The inputs that functions take in are called arguments. A function can have one or more arguments.

A common function in the C programming language is printf();. This prints something to the screen. It's a function used to say something.

The parentheses () are the inputs to the function, where the arguments go in – that is, what we actually want to say and print to the screen. What is between the parentheses gets printed out.

In printf("Hello world!"); , Hello world! is the input to the printf function. Here, we are calling a function called printf and we are giving it an argument that is a string. This says literally, print 'Hello world! 'to the screen.

Function outputs in C

There are two types of function output:

First, outputs can just be something visual, an immediate visual effect, something quickly printed to the screen.

You can't do anything more with that output after the effect. Like in the case of printf("Hello world!");, the output is the string "Hello world!" printed to the screen, and that's it. You can't use that string in some other way, because printf has no return value.

These types of functions are known as side effects, meaning they have an immediate observable effect without returning a value.

Also, a function like printf is a function invocation and in the stdio library is defined as int printf(const char *format,...);.

Second, the output can be reusable, and has a return value. A return value is a value passed back to the programmer and stored in a variable for later use.

In such cases, there is no immediate effect – nothing gets printed to the screen. The output is instead return to us, stored as information and saved in a variable.

How to Define a Method in C

There are three things you need to have in the first line, the decelerating line, when defining a function.

1) The return type

This is the very first keyword used, and how a function starts indicates the return value.

For example in a function like: void say_something(void), the first void means that the function has no return value.

In another example with a different function, int main(void), we specify and define its return data type, in this case an int. The function's output will be an int data type and will be returned to where the function is called.

2) The function name

The name can be anything we want, although it is best practice to name the methods after what they intend to do.

3) None or one or more arguments

These are the function's inputs, and the data type of those inputs.

In void say_something(void), the void inside the parentheses is a keyword for the argument and a placeholder for 'nothing'. It means it takes In no inputs. In cases like this, the argument is also called a parameter.

Parameters are essentially variables declared in the function, inside the parentheses like the void keyword. They act as a placeholder to access the function input data, the arguments.

Parameters refer to the value being passed in to the method. This means that when we later call the function, we pass the actual values to it, the arguments to the function.

How to Call a Function in C

We can call a function like:

void say_hi(void)
{
    printf("hello");
}

By writing the function's name, followed by any arguments in parentheses and a semicolon like say_hi();. The say_hi function takes in no inputs and has no return value. When called it just prints 'hello' to the screen.

Another function like:

int square(int n)
{
    return n * n
}

is called in the same way as the previous example. In this case, the square function take in an input and has a return value (both are ints). The input it takes in is the parameter called n, that returns an int when the function is called.

The word return specifies that what will get returned, the input n multiplied by itself.

For example, when the function is called square(3);, n acts as a variable that points to the parameter that has been passed in to the function, like 3. It is like we have set n = 3. The value that gets returned is 9.

Functions are meant to be reused, so we can use it anytime we wish to square a number:

#include <stdio.h>

  int square(int x)
  {
    return x * x;
  }

  int main(void)
  {
   printf("%i\n", square(2));
   printf("%i\n", square(4));
   printf("%i\n", square(8));
 }

How to Use Boolean Expressions in C

A boolean expression is an expression that evaluates to one of two values, true or false. They get their name after the mathematician, philosopher, and logician George Boole.

_George Boole Image Source Wikimedia_

We use boolean expressions to compare two values and they are particularly helpful in control flow.

Every non-zero value is true and 0 is false.

We can combine boolean expressions with the use of the different logical operators, like && (and), || (or) and ! (not) mentioned earlier in the article.

Different combinations of values and operators lead to different output results, which can be expressed in a truth table, a mathematical table used to represent logical equations wich result to 1 or 0 or their equivalent true or false.

When comparing two boolean values using the && (and) operator, both values have to equate to true for the combined experssion to be true.

For example if someone asks us "Do you want a pizza and a salad?", the only way for the expression to be true is for us to want both a pizza and a salad (so our answer is yes to both). If the answer to one of them is not true then the whole expression is false.

Truth Table for &&

Unlike &&, the || operator lets us take action if one or both values are true. So this operator is not exclusive, either one of the comparissons has to be true for the experssion to evaluate to true or even both.

This is quite unique to computing, since in our example question used earlier, if instead of AND we changed it to OR, the statement 'Do you want pizza or a salad?' does not mean that you want both. You want one or the other, not necessarily both together.

Truth table for ||

Lastly, the ! (not) operator is used for negation, meaning it turns true to false and false to true.

!true is false
!false is true

How to Use Conditional Statements in C

Conditional statements take a specific action based on the result of a comparisson that takes place. The act of doing one thing if a particular condition is true and possibly a different thing if that particular condition turns out to be false is called control flow.

Certain parts of the program may not run depending on the results or depending on certain user input. The user can go down different paths depending on the various forks in the road that come up during a program's life.

Programs with conditional statements use if blocks primaraly. The if blocks use boolean expressions that can only be true or false and they make decisions depending on those resulting values. We denote an if block statement by using curly braces, {}, and indendation of the code that follows.

#include <stdio.h>
int main(void)
{
int x = 2;
int y = 3;

if (x < y)

// x < y is a boolean expression,it can only be true or false.
// If whatever is in the parentheses is true 
//-in this case is x is actually less than y-
//run the code that follows
{
    printf("x is less than y"); 

// Because x < y is true that statement will be printed
}

}

An if statement on its own is not that helpful especially as the programs grow larger and larger. So in that case the if statement is accompanied by an else statement.

These mean that 'if this condition is true do the following, else do this instead'. The else keyword is the solution for when the if condition is false and therefore doesn't run.

int main(void)
{ 
int  x = 1;
int  y = 2;

if ( x > y)
{
  printf("x is larger than y");
}

else 

{  
  printf("x is less than y");
// Because  x > y is false ,
// this block of code will be executed
// resulting in printing the statement of the else branch
}

}

If we wish to chose between more than just two options and want to have a greater variety in statement and actions, then we can introduce an else if condition.

This means that 'If this condition is true, do this. If it is not, do this thing instead. However, if none of the above is true, finally do this instead.'

#include <stdio.h>
int main(void)
{
  int x = 2;
  int y = 2;

  if(x < y)
   // if this condition is true run this block
  {
    printf("x is less than y");
  }
 else if(x > y)
  / / if the above statement was true run this block instead
 { 
    printf("x is greater than y");
 } 
 else  
   // if this block of code runs 
   //it runs because x < y was false 
  //and so was x > y 
  //so it means x == y
 {
    printf("x is equal to y");
 }
}

How to Use Loops in C

A loop is an isolated behavior or a specific set of instructions that are repeated a certain number of times, over and over again, until a condition is met. It is the same action, the same code, being repeated again and again.

While loops in C

Before they run any code, while loops have to check a condition. If it is met, the code runs. If not, the code doesn't take any action. So, code is not guaranteed to run even at least one time if a condition is not met.

There are different types of while loops. One of them is an infinite loop.

#include <stdio.h> 
int main(void)
{

    while(true)
    {
        printf("Hello world");
    }
}

The while keyword is used along with a required boolean expression, true in this case (which always stays true).

After printing the line of code inside the curly braces, it continuously checks wether it should run the code again. As the answer is always yes (since the condition it needs to check is always true each and every time), it runs the code again and again and again.

In this example the only way to stop the program and escape from the endless loop is running Ctrl + C in the terminal.

If the condition was false, it would never run the code inside the curly braces.

Another loop, is a loop that repeats something a certain number of times.

#include <stdio.h>
int main(void)
{
    int i = 0;

    while(i < 10)
    {
    //while i is less than 10 run this code
        printf("Hello world");
    // and then increment
        i++
    //check the condition everytime
  //once the code in the curly braces is run, check if i is still less than 10.
  // If so run code + increment again and check again
    //loop will eventually end when i reaches 10
    }
}

Do-while loops

#include <stdio.h>

int main(void)
 {
   int i = 10;
   do {
      printf("the value of i: %i\n", i);
      i++;
   }
  while( i < 20 );
}

Compared to the while loop, the do- while loop is guaranteed to run at least once and execute the code inside the curly braces at least one time.

It first does something and then checks a condition. This is useful when we want to repeat something at least once but for an unknown number of times.

In our example, the code will run at least one time and the statement will be printed at least once. Next, the value is incremented. It then checks if the value is less than 20, and if so, it runs the code again. It will stop running the code once the value being incremented each time is no longer less than 20.

Resources to continue learning C

This marks the end of this intoduction to the C programming language! Nice work for making it through to the end.

I hope this gave you an insight into the 'whys' and the 'hows' of the language and the fundamentals you need to know to start writing basic programs in C.

If you want to go more in depth, build some projects, and problem solve using C, give CS50 Introduction To Computer Science a go.

If you enjoy learning by reading books, I recommend the ones below:

• C programming absolute beginners guide
• Programming in C

If you enjoy learning by watching videos and coding along,check out the C Programming Tutorial for Beginners video on freeCodeCamp's YouTube channel.

Thanks for reading and happy coding!

Within minutes of watching MyCodeSchool, you could immediately tell that:

1. These developers were really passionate about computer science. And
2. They were exceptionally good at teaching it.

At the time, I was a 31-year old teacher trying to get my first job as a software engineer. And like most people, I watched the videos. I took notes. And eventually I went on my merry way.

It was only years later that I noticed MyCodeSchool had stopped publishing videos. And I discovered the tragic reason why.

MyCodeSchool's YouTube channel, which – aside from a single video published in 2016, went dark nearly 6 years ago.

The more I dug, the more I realized how important this story was. And now I am going to share that story.

I'm also going to share with you some never-before published photos and insights from the early days of MyCodeSchool.

Every developer should learn this story of friendship between these two teachers, and how they – for a short time – took the programming world by storm.

This story is sad. But it is also inspiring. And I feel honored to relay it to you.

Here's how Harsha and Animesh took decades worth of computer science wisdom and made it easily accessible to millions of students around the world.

The Monkey With His Hand Stuck in a Jar

Animesh Nayan was a mediocre student who rarely attended class. He was a "last bencher" who was only able to pass school because his friends would cover for him when his professors took attendance.

But Animesh loved programming. And he was good at it. Outside of his classes, he immersed himself in the world of algorithms, data structures, and systems design.

Animesh became so good in fact that he was able to land a coveted job as a software engineer at Microsoft right out of school.

I spoke with Animesh at length, and told me his views on Indian higher education bluntly: "We graduate a large number of computer science engineers every year, but only 15 to 20% of them are employable in the IT-enabled services industry. And only 3% of them are employable in IT product companies, which require a deeper understanding of computer science concepts like data structures and algorithms."

"With the current standard of computer science education, we are catering to the industry more in terms of quantity and less in terms of quality."

And as fate would have it, tackling this "quality problem" Animesh had identified would become the central focus of his life.

But he wouldn't realize that until nearly 5 years later, after going through the motions at Microsoft. He was good at his job, but it wasn't his calling. This was what society wanted for him. It was not what he wanted for himself.

"First I was trying to make my father happy by getting good grades and getting a good job. Then I was trying to make my manager at work happy by fixing 20 software bugs in a week. I was bored of seeking validation and not being connected to my inner self. I thought, people take me seriously if I told them I work for Microsoft. But what is my identity beyond that?"

Animesh likened his predicament to a monkey who had reached into a jar to grab some peanuts. In order to pull his hand out, he had to let go of some of the peanuts. But the monkey's instincts prevent him from doing this, so he just stays there, stuck. (And yes, this is a real-life method used to trap monkeys.)

"Quite often when it comes to life, we behave like these monkeys. We hold on to something like a source of money even when it’s making us miserable."

But working for Microsoft did bring him prestige and made him famous among his extended family. Many of his friends and relatives who were struggling through computer science programs reached out to him asking for mentorship. They hoped to reproduce Animesh's success for themselves. And Animesh did his best to help them.

"I figured out that most of them do not have good fundamentals, and they lack in what I'll call the core skill in computer science - programming."

He saw what Salman Khan had accomplished through his math videos on Khan Academy, and thought he could do something similar for programming and computer science.

"My approach was to make a complex computer science concept easy to understand with a good script. I would spend weeks just thinking about how to simplify and explain an algorithm in the best possible way."

In 2012, he published his first 15-minute lecture to YouTube.

"I felt embarrassed listening to my own voice. But my wife encouraged me, so I published it anyway. Surprisingly not many people were teaching computer science in easy to understand language back then. My video was soon ranking at top for a query like 'time complexity'. I felt encouraged and created some more videos."

By mid 2012, he had published several videos, and fellow programmers began reaching out to collaborate. But Animesh had his sights set on one programmer in particular – his long-time friend and fellow IIIT Allahabad graduate, Harsha Suryanarayana.

The Humble Fool

Harsha was no ordinary unemployed computer science grad. He was a legendary competitive programmer. He was well-known not just around campus, but internationally.

Harsha Suryanarayana

Here are some of Harsha's achievements:

• He got a perfect score on all 3 of his ICSE exams.
• He represented India at the ACM's International Collegiate Programming Contest.
• He achieved the "red" ranking on Top Coder, and was the highest ranked Indian programmer on the entire competitive programming platform.
• And he was the first Indian ever to qualify for a Google Code Jam.

Harsha's reputation was such that his friends referred to him as "Lord Harsha."

But Harsha himself preferred to go by a less grand handle: "Humblefool."

Harsha (left) at ACM ICPC World finals

Animesh says of Harsha: "I had tried competitive programming too, and my rating was not even half of his. I remember writing an email and telling him about MyCodeSchool and thinking that he would be too busy to reply."

But Harsha called him the next day. And he was full of ideas for MyCodeSchool.

Instead of getting a job at a big software company like Animesh had done, Harsha had been busy conducting programming bootcamps for computer science students. And Harsha invited Animesh to come and assist him in teaching one.

"His boot camps were not getting the kind of response I expected. He talked really fast and probably assumed that some concepts and details were too trivial to bother explaining. Even though he was the nicest guy, many students weren't participating and felt too stupid to ask questions. Harsha sensed that too, but did not know how to break the barriers and shift his frame of reference. He needed to lower his assumptions and get in a good flow with everyone in the class."

And that is where Animesh saw an opportunity. He didn't know half of the computer science that Harsha knew. But he was good at breaking concepts down and explaining them. He suspected they could make them a powerful team. And he soon got a chance to put this assumption to the test.

The Microsoft India Development Center wanted Harsha and Animesh to help train and onboard their new hires. Harsha created the coding challenges and Animesh focused on the presentation. They looked for ways they could gamify the experience, add humor, and get students to work in teams.

Animesh (second from right) with participants from one of his bootcamps

Their bootcamp got a standing ovation and high marks from participants, and Microsoft wanted to hire them for more training. It was great validation for Harsha and Animesh's team-based teaching approach. But they had their sights set on something much larger than corporate training.

They spent the next year teaching competitive programming. They taught a winter coding bootcamp together.

Harsha teaching at the winter coding camp in 2013

They went through a startup accelerator together and launched a website, mycodeschool.com. They even hired on a team of interns.

From Left to Right: Animesh, interns Ashwin, Vishal, Lokesh, and Shashank, and Harsha

"We discussed a lot of philosophy, and how chasing only money wasn’t the best way to live life. Our approach to doing a startup was quite laid back. We were not too concerned about raising money or growing fast. We just wanted to have fun with whatever we were doing."

The MyCodeSchool team playing laser tag

You Never Realize You're Living Through the Renaissance Until It's Over

"I remember. It was June 15, 2014. I got an email from Microsoft inviting us to conduct another bootcamp for them. I wanted to discuss it with Harsha and so I called him that evening. He did not pick up. I called him a few times, but no response. He would call back soon as he always does, I thought."

The next morning, Animesh got a call from a friend telling him to check the local news.

Harsha and his wife, Neha, had been crossing the street at night when a car slammed into them. Neha was in the hospital, and would ultimately recover from her injuries. But Harsha wouldn't. The doctors pronounced him dead upon arrival. He was only 32 years old.

"What? Are you sure it’s our Harsha?" Animesh recalled. "I couldn’t believe it. But the news was true. I was devastated."

There was an immediate outpouring of grief across the competitive programming community.

Top Coder dedicated a match in his honor.

TopCoder dedicated a match to Harsha's memory. At the time, Harsha was the highest-rated TopCoder member in the algorithm track in all of India.

Animesh said of his friend at: "Harsha has chosen to go to heaven because God needed a genius programmer there."

Life After MyCodeSchool

Animesh reflected on that period of his life. "The next few months were very hard. I tried to continue, but felt lonely, sad, and overwhelmed."

Animesh decided he needed a change of pace. His wife was working at Google in India, and was able to transfer internally to the US. "I thought, why not. This may be a good change. Silicon Valley is a really exciting place and I had always wanted to experience it."

Within a few months, Animesh had gotten offers from tech giants like Facebook. Today he works as an engineer on Google's search team, working on both the Google and YouTube search engine algorithms.

Speaking with Animesh as he sat at his kitchen table, surrounded by his family, he told me: "I am a father of 2 wonderful kids now and life is good. But, there is a force that keeps creating an inner conflict in me. Everyday, I get some emails in my inbox thanking me for MyCodeSchool and asking me why I don't create videos anymore."

"I do not know what to say. I want to get back to teaching, but it’s just hard. I want to give a lot of time to my kids and it’s not possible to get back to it unless I quit my regular job and do it full time. This force is growing everyday. Maybe it will lead me back to my passion for teaching once again. I do not know yet."

Then Animesh's thoughts return to Harsha, and he recalls a conversation they had. "I was being the typical entrepreneur and asking him to think about scaling so we could reach many more. And he said something interesting. Maybe we can just inspire a few people to teach, and they can inspire few more to teach and the chain would grow. We need far too many motivated teachers, and it can’t be just us anyway. It’s like being a candle that can light up some more candles. Something inspired the two of us and put that light in us. We were not the first and we won’t be the last. We only are the intermediate links in this chain."

The Spirit of MyCodeSchool Lives On in the freeCodeCamp Community

I often wonder what would have happened if Harsha were still with us, and if he and Animesh were still experimenting with new ways of teaching programming and computer science.

One thing is for sure: we will remember the work of Harsha and Animesh, the time they spent together, and the ground-breaking courses that resulted.

I speak for many teachers when I say that their work has inspired me, and that communities like freeCodeCamp would not exist without the vision of these pioneers.

Animesh has given me permission to publish several anthologies of some of MyCodeSchool's best algorithm and data structure explanations on freeCodeCamp's YouTube channel. Starting in December, we will publish several full-length courses derived from MyCodeSchool's archive of computer science courses.

I am honored to help bring the teaching of these two legendary teachers to a new audience of aspiring developers.

In closing, I want to share this anecdote Animesh mentioned in my conversations with him:

A student, aware of Harsha's genius, asked him why he chose to spend all of his time teaching others.

Harsha thought for a while and said, “I have always liked the stories where an underdog wins. I just want to be part of one of those stories.”

It may seem like something automatic that we take for granted, but there is a whole process that happens behind the scenes that makes it run.

So...The Internet. What is it?

The Internet is actually a wire. Well, many wires that connect computers all around the world.

The Internet is also infrastructure. It's a global network of interconnected computers that communicate through a standardised way with set protocols.

Really, it's a network of networks. It's a fully distributed system of computing devices and it ensures end to end connectivity through every part of the network. The aim is for every device to be able to communicate with any other device.

_Visualisation of a possible routing path on the Internet. Image from Wikimedia Foundation._

The Internet is something we all use everyday, and many of us can't imagine our lives without it. The internet and all the technological advances it offers has changed our society. It has changed our jobs, the way we consume news and share information, and the way we communicate with one another.

It has also created so many opportunities and has helped helped humanity progress and has shaped our human experience.

There is nothing else like it – it's one of the greatest inventions of all time. But do we ever stop to think why it was created in the first place, how it all happened, or by whom it was created? How the internet has become what it is today?

This article is more of a journey back in time. We'll learn about the origins of the Internet and how far it has come throughout the years, as this can be beneficial in our coding journeys.

Learning about the history of how the Internet was created has made me realise that everything comes down to problem solving. And that is what coding is all about. Having a problem, trying to find a solution to it, and improving upon it once that solution is found.

The Internet, a technology so expansive and ever-changing, wasn't the work of just one person or institution. Many people contributed to its growth by developing new features.

So it has developed over time. It was at least 40 years in the making and kept (well, still keeps) on evolving.

And it wasn't created just for the sake of creating something. The Internet we know and use today was a result of an experiment, ARPANET, the precursor network to the internet.

And it all started because of a problem.

Scared of Sputnik

It was in the midst of the Cold War, October 4 1957, that the Soviets launched the first man made satellite into space called Sputnik.

As it was the world's first ever artificial object to float into space, this was alarming for Americans.

The Soviets were not only ahead in science and technology but they were a threat. Americans feared that the Soviets would spy on their enemies, win the Cold War, and that nuclear attacks on American soil were possible.

_Image from Wikimedia Foundation_

So Americans started to think more seriously about science and technology. After the Sputnik wake up call, the space race began. It was not long after that in 1958 the US Administration funded various agencies, one of them being ARPA.

ARPA stands for Advanced Research Project Agency. It was a Defence Department research project in Computer Science, a way for scientists and researchers to share information, findings, knowledge, and communicate. It also allowed and helped the field of Computer Science to develop and evolve.

It was there that the vision of J.C.R. Licklider, one of the directors of ARPA, would start to form in the years to come.

Without ARPA the Internet would not exist. It was because of this institution that the very first version of the Internet was created – ARPANET.

Creating a Global Network of Computers

Although Licklider left ARPA a few years before ARPANET was created, his ideas and his vision laid the foundation and building blocks to create the Internet. The fact that it has become what we know today we may take for granted.

Computers at the time were not as we know them now. They were massive and extremely expensive. They were seen as number-crunching machines and mostly as calculators, and they could only perform a limited number of tasks.

So in the era of mainframe computers, each one could only run a specific task. For an experiment to take place that required multiple tasks, it would require more than one computer. But that meant buying more expensive hardware.

The solution to that?

Connecting multiple computers to the same network and getting those different systems to speak the same language in order to communicate with one another.

The idea of multiple computers connected to a network was not new. Such infrastructure existed in the 1950's and was called WANs (Wide Area Networks).

However, WANs had many technological limitations and were constrained both to small areas and in what they could do. Each machine spoke it's own language which made it impossible for it to communicate with other machines.

So this idea of a 'global network' that Licklider proposed and then popularised in the early 1960's was revolutionary. It tied in with the greater vision he had, that of the perfect symbiosis between computers and humans.

He was certain that in the future computers would improve the quality of life and get rid of repetitive tasks, leaving room and time for humans to think creatively, more in-depth, and let their imagination flow.

That could only come to fruition if different systems broke the language barrier and integrated into a wider network. This idea of "Networking" is what makes the Internet we use today. It's essentially the need for common standards for different systems to communicate.

Building a Distributed Packet Switched Network

Up until this point (the end of the 1960's), when you wanted to run tasks on computers, data was sent via the telephone line using a method called "Circuit switching".

This method worked just fine for phone calls but was was very inefficient for computers and the Internet.

Using this method you could only send data as a full packet, that is data sent over the network, and only to one computer at a time. It was common for information to get lost and to have to re-start the whole procedure from the beginning. It was time consuming, ineffective, and costly.

And then in the Cold War era, it was also dangerous. An attack on the telephone system would destroy the whole communication system.

The answer to that problem was packet switching.

It was a simple and efficient method of transferring data. Instead of sending data as one big stream, it cuts it up into pieces.

Then it breaks down the packets of information into blocks and forwards them as fast as possible and in as many possible directions, each taking its own different routes in the network, until they reach their destination.

Once there, they are re-assembled. That's made possible because each packet has information about the sender, the destination, and a number. This then allows the receiver to put them back together in their original form.

This method was researched by different scientists, but the ideas of Paul Baran on distributed networks were later adopted by ARPANET.

Baran was trying to figure out a communication system that could survive a nuclear attack. Essentially he wanted to discover a communication system that could handle failure.

He came to the conclusion that networks can be built around two types of structures: centralised and distributed.

From those structures there came three types of networks: centralised, decentralised, and distributed. Out of those three, it was only the last one that was fit to survive an attack.

_Image from RAND CORPORATION_

If a part of that kind of network was destroyed, the rest of it would still function and the task would simply be moved to another part.

At the time, they didn't have rapid expansion of the network in mind – we didn't need it. And it was only in the years to come that this expansion started to take shape. Baran's ideas were ahead of his time, however, they laid the foundation for how the Internet works now.

The experimental packet switched network was a success. It led to the early creation of the ARPANET architecture which adopted this method.

How ARPANET Was Built

What started off as a response to a Cold War threat was turning into something different. The first prototype of the Internet slowly began to take shape and the first computer network was built, ARPANET.

The goal now was resource sharing, whether that was data, findings, or applications. It would allow people, no matter where they were, to harness the power of expensive computing that was far away, as if they were right in front of them.

Up until this point scientists couldn't use resources available on computers that were in another location. Each mainframe computer spoke its own language so there was lack of communication and incompatibility between the systems.

In order for computers to be effective, though, they needed to speak the same language and be linked together into a network.

So the solution to that was to build a network that established communication links between multiple resource-sharing mainframe supercomputers that were miles apart.

The building of an experimental nationwide packet switched network that linked centers run by agencies and universities began.

On October 29 1969 different computers made their first connection and spoke, a 'node to node' communication from one computer to another. It was an experiment that was about to revolutionize communication.

The first ever message was delivered from UCLA (University of California, Los Angeles) to SRI (the Stanford Research Institute).

It read simply "LO".

What was meant to be "LOGIN" was not feasible at first, as the system crashed and had to be rebooted. But it worked! The first step had been made and the language barrier had been broken.

By the end of 1969 a connection had been established between four nodes on the whole network which included UCLA, SRI, UCSB (University of California Santa Barbara) and the University of Utah.

But the network grew steadily throughout the years and more and more universities joined.

By 1973 there were even nodes connecting to England and Norway. ARPANET managed to connect these supercomputing centers run by universities together into its network.

One of the greatest achievements of that time was that a new culture was emerging. A culture that revolved around solving problems via sharing and finding the best possible solution collectively via networking.

During that time scientists and researchers were questioning every aspect of the network – technical aspects as well as the moral side of things, too.

The environments where these discussions were taking place were welcoming for all and free of hierarchies. Everyone was free to express their opinion and collaborate to solve the big issues that arose.

We see that kind of culture carrying over to the Internet of today. Through forums, social media, and the like, people ask questions to get answers or come together to deal with problems, whatever they may be, that affect the human condition and experience.

As time passed, more independent packet switched networks emerged that were not related to ARPANET (which existed on an international level and started to multiply by the 1970's) . That was a new challenge.

These different networks had their own dialects, and their own standards for how data was transferred. It was impossible for them to integrate into this larger network, the Internet we know today.

Getting these different networks to speak to one another – or Internetworking, a term scientists used for this process – proved to be a challenge.

A Need for Common Standards

Now our devices are designed so that they can connect to the wider global network automatically. But back then this process was a complex task.

This worldwide infrastructure, the network of networks that we call the Internet, is based on certain agreed upon protocols. Those are based on how networks communicate and exchange data.

From the early days at ARPANET, it still lacked a common language for computers outside its own network to be able to communicate with computers on its own network. Even though it was a secure and reliable packet-switched network.

How could these early networks communicate with one another? We needed the network to expand even more for the vision of an 'global network' to become a reality.

To build an open network of networks, a general protocol was needed. That is, a set of rules.

Those rules had to be strict enough for secure data transfer but also loose enough to accommodate all the ways that data was transferred.

TCP/IP Saves the Day

Vint Cerf and Bob Khan began working on the design of what we now call the Internet. In 1978 the Transmission Control Protocol and Internet Protocol were created, otherwise known as TCP/IP.

The rules for the Interconnection were:

• The independent networks were not required to change
• There was an effort to achieve communication
• Internal networks would exist in addition with gateways that would connect these networks. Their job would be to translate between the networks. There would be one universal, agreed upon protocol for that.
• There would be no central control, no one person or organization in charge.

As Cerf explained:

The job of TCP is merely to take a stream of messages produced by one HOST and reproduce the stream at a foreign receiving HOST without change.

The Internet Protocol (IP) makes locating information possible when looking among the plethora of machines available.

So how does data travel?

So how does a packet go from one destination to another? Say from the sending destination to the receiving one? What role does TCP/IP play in this and how does it make the journey possible?

When a user sends or receives information, the first step is for TCP on the sender's machine to break that data into packets and distribute them. Those packets travel from router to router over the Internet.

During this time the IP protocol is in charge of the addressing and forwarding of those packets. At the end, TCP reassembles the packets to their original state.

What Happened Next with the Internet?

Throughout the '80s this protocol was tested thoroughly and adopted by many networks. The Internet just continued to grow and scale at a rapid speed.

The interconnected global network of networks was finally starting to happen. It was still mainly used widely by researchers, scientists, and programmers to exchange messages and information. The general public was quite unaware of it.

But that was about to change in the late '80s when the Internet morphed again.

This was thanks to Tim Berners Lee who introduced the Web – how we know and use the Internet today.

The internet went from just sending messages from one computer to another to creating an accessible and intuitive way for people to browse what was at first a collection of interlinked websites. The Web was built on top of the Internet. The Internet is its backbone.

I hope this article gave some context and insight into the origins of this galaxy of information we use today. And I hope you enjoyed learning about how it actually all started and the path it took to becoming the Internet we know and use today.

Something on your Linux box isn’t running? Troubleshooting is your friend. But before you even get there, shouldn’t you make sure the underlying service is actually running? Sometimes the configuration files are by default set to inactive.

You can use systemctl status to find out whether a service — OpenSSH in this example — is running on your machine:

$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2017-05-15 12:37:18 UTC; 4h 47min ago
Main PID: 280 (sshd) <2>
Tasks: 8
Memory: 10.1M
CPU: 1.322s
CGroup: /system.slice/ssh.service
├─ 280 /usr/sbin/sshd -D
├─ 894 sshd: ubuntu [priv]
├─ 903 sshd: ubuntu@pts/4
├─ 904 -bash
├─1612 bash
├─1628 sudo systemctl status ssh
└─1629 systemctl status ssh
[...]

In this case, as you can see from the Active line of the output, everything is fine. If you did have to crank it up yourself though, you’d use systemctl once again, but this time with start in place of status. Bored with your new toy? systemctl stop will put it away for you.

# systemctl stop ssh

That systemctl fellow seems nice enough, but we’ve barely had the chance to meet him. Let’s dig a big deeper.

Linux process management

First, just what is systemctl and what’s it actually doing? To properly answer that question, you’ll have to think for a bit about how Linux manages system processes in general. And since it’s always nice to meet new friends, you will also learn about some process tracking tools to make understanding the way things work easier.

Software, as I’m sure you already know, is programming code containing instructions to control computer hardware on behalf of human users. An operating system is a tool for organizing and managing software packages so that they can effectively leverage a computer’s hardware resources.Organizing and managing processes for a complex multi-process and multi-user operating environment is no simple task. To make it work, you’ll need some kind of traffic cop to tightly control the many moving parts. Let me introduce you to systemctl, a hard-working officer in the traffic division of the Linux Police Department.

The availability and responsiveness of many system services are managed by systemd’s systemctl process manager

Viewing processes with the ps command

Let’s pull out an electron microscope and see if we can’t spot an actual process in its natural habitat. The very first process to wake up and get everything else going when a Linux computer boots is called init (although as we’ll soon discover, that name can be misleading). You can see for yourself that init is first by running the following ps command exactly the way it’s printed here — I’ll explain the details in just a minute.

$ ps -ef | grep init
root 1 0 0 12:36 ? 00:00:00 /sbin/init
ubuntu 1406 904 0 16:26 pts/4 00:00:00 grep --color=auto init

The rightmost column of output (/sbin/init on the first line) represents the location and name of the file behind the process itself. In this case, it’s a file called “init” that lives in the /sbin directory. The leftmost column on this first line contains the word root and tells us that the owner of this process is the root user. The only other piece of information that interests us right now is the number 1, which is the process ID (PID) of the init process. The only way you’re going to get PID 1 is by getting there before anyone else.

By the way, the second line displayed by that ps command is the process assigned to the grep command itself. Note how its owner is ubuntu (my username) and its PID is much higher than 1.

Before moving on it’s worth spending a bit more time with ps. As you’ve seen, ps displays information about active processes. It’s often important to have access to process-related information so we can properly plan and troubleshoot system behavior. You can expect to use ps early and often.

If you were to type just ps and run it, you’d probably get only two results: the first, a process called bash that represents the Bash command interpreter being used by your current shell session, and the most recent command (which, of course, was ps). But by looking at the PID assigned to Bash (7447, in this example), you just know there are lots and lots of other processes already hard at work somewhere on your system. These will have been spawned by parent shells going all the way back to the init process itself.

$ ps
PID TTY TIME CMD
7447 pts/3 00:00:00 bash
8041 pts/3 00:00:00 ps

Adding the -e argument to ps as we did above will return not only the processes running in your current child shell, but all the processes from all parent shells right back up to init.

A parent shell is a shell environment from within which new (child) shells can subsequently be launched and through which programs run. You can think of your GUI desktop session as a shell, and the terminal you open to get a command line as its child. The top level shell (the grandparent?) is the one that is run first when Linux boots.

If you want to visualize parent and child shells/processes, you can use the pstree commmand (adding the -p argument to display the PID numbers for each process). Note how the very first process (assigned PID 1) is systemd. On older versions of Linux, this would have been called init instead.

$ pstree -p
systemd(1)─┬─agetty(264)
├─agetty(266)
├─agetty(267)
├─agetty(268)
├─agetty(269)
├─apache2(320)─┬─apache2(351)
│ ├─apache2(352)
│ ├─apache2(353)
│ ├─apache2(354)
│ └─apache2(355)
├─cron(118)
├─dbus-daemon(109)
├─dhclient(204)
├─dockerd(236)─┬─docker-containe(390)─┬─{docker-containe}(392)
│ │ └─{docker-containe}(404)
│ ├─{dockerd}(306)
│ └─{dockerd}(409)
├─mysqld(280)─┬─{mysqld}(325)
│ ├─{mysqld}(326)
│ └─{mysqld}(399)
├─nmbd(294)
├─rsyslogd(116)─┬─{in:imklog}(166)
│ ├─{in:imuxsock}(165)
│ └─{rs:main Q:Reg}(167)
├─smbd(174)─┬─smbd(203)
│ └─smbd(313)
├─sshd(239)───sshd(840)───sshd(849)───bash(850)───pstree(15328)
├─systemd-journal(42)
└─systemd-logind(108)

Go ahead and try all these commands on your own machine. Even on a quiet system, you’ll probably see dozens of processes; a busy desktop PC or server can easily have thousands.

Working with systemd

There’s something interesting about that /sbin/init file we just saw. “file” is a venerable Unix program that gives you insider information about a file. If you run file with /sbin/init as its argument, you’ll see that the init file is not actually a program, but simply a symbolic link to a program called systemd.

$ file /sbin/init
/sbin/init: symbolic link to /lib/systemd/systemd

After many years of fragmentation and some vigorous political infighting, nearly all Linux distributions now use the same process manager: systemd. systemd is a drop-in replacement for the init process. By “drop-in replacement” I mean that, even if the way it gets things done can be quite different, to the casual observer, systemd functions just like init always did. That’s why the /sbin/init file is now really nothing more than a link to the systemd program.

This is all a bit theoretical since you’ll probably never actually invoke the systemd program itself by name — either directly or through its /sbin/init front end. This is because, as you’ve already seen, the key administration tasks are handled by systemctl on behalf of systemd.

Technically, systemd’s primary job is to control the ways individual processes are born, live their lives, and then die. The systemctl command we used above is the tool of choice for those tasks. But — somewhat controversially — the systemd developers expanded the functionality far beyond the traditional role of process management to take control over various system services. Included under the new systemd umbrella are tools like a logging manager (journald), network manager (networkd), and device manager (you guessed it: udevd). Curious? The “d” stands for daemon; a background system process.

This article is adapted from chapter 3 (Remote connectivity: safely access networked machines) of my Manning “Linux in Action” book. There’s lots more fun where this came from — including Linux and Docker admin courses on Pluralsight and a hybrid course called Linux in Motion that’s made up of more than two hours of video and around 40% of the text of Linux in Action. Who knows…you might also enjoy my other books and courses.

Laplace, Bayes, and machine learning today

It may not be a question that you were worrying much about. After all, it appears to happen every day without fail.

But what is the probability the sun will rise tomorrow?

Believe it or not, this question was given consideration by one of mathematics’ all-time greats Pierre-Simon Laplace in his pioneering work of 1814, “Essai philosophique sur les probabilités”.

Fundamentally, Laplace’s treatment of the question was intended to illustrate a more general concept. It was not a serious attempt to estimate whether the sun will, in fact, rise.

In his essay, Laplace describes a framework for probabilistic reasoning that today we recognise as Bayesian.

The Bayesian approach forms a keystone in many modern machine learning algorithms. But the computational power required to make use of these methods has only been available since the latter half of the 20th Century.

(So far, it appears current state-of-the-art AI is keeping quiet on the issue of tomorrow’s sunrise.)

Laplace’s ideas are still relevant today, despite being developed more than two centuries ago. This article will review some of these ideas, and show how they are used in modern applications, perhaps envisaged by Laplace’s contemporaries.

Pierre-Simon Laplace

Born in the small Normandy commune of Beaumont-en-Auge in 1749, Pierre-Simon Laplace was initially marked out to become a theologian.

However, while studying at the University of Caen, he discovered a brilliant aptitude for mathematics. He transferred to Paris, where he impressed the great mathematician and physicist Jean le Rond d’Alembert.

At the age of 24, Laplace was elected to the prestigious Académie des Sciences.

Laplace was an astonishingly prolific scientist and mathematician. Amongst his many contributions, his work on probability, planetary motion, and mathematical physics stand out. He counted figures such as Antoine Lavoisier, Jean d’Alembert, Siméon Poisson, and even Napoleon Bonaparte, as his collaborators, advisers, and students.

Laplace’s “Essai philosophique sur les probabilités” was based upon a lecture he delivered in 1795. It provided a general overview of ideas contained within his work “Théorie analytique des probabilités”, published two years earlier in 1812.

In “Essai philosophique”, Laplace provides ten principles of probability. The first few cover basic definitions, and how to calculate probabilities relating to independent and dependent events.

Principles eight, nine, and ten concern the application of probability to what we might describe today as cost-benefit analysis.

The sixth is an important generalization of Thomas Bayes’ eponymous theorem of 1763.

It states that, for a given event, the likelihood of each possible cause is found by multiplying the prior probability of that cause by a fraction.

This fraction is the probability of the event arising from that particular cause, divided by the probability of the event occurring by any cause.

Probability of A-given-B equals probability of A times probability of B-given-A, divided by probability of B

This theorem’s influence within machine learning cannot be overstated.

The seventh principle is the one that has caused the most controversy since its publication. However, the actual wording is innocuous enough.

Rather, it is Laplace’s choice of discussing the probability of the sun rising the next day by way of illustrative example that has in turn drawn derision and objection over the following two centuries.

The rule of succession is still used today under various guises, and sometimes in the form Laplace originally described.

In fact, the rule of succession represents an important early step in applying Bayesian thinking to systems for which we have very limited data and little or no prior knowledge. This is a starting point often faced in modern machine learning problems.

Laplace’s rule of succession

The seventh principle of probability given in Laplace’s “Essai philosophique” is, in essence, straightforward.

It states that the probability of a given event occurring is found by summing the probability of each of its potential causes multiplied by the probability of that cause giving rise to the event in question.

Laplace then proceeds to outline an example based upon drawing balls from urns. So far, so good. Nothing contentious yet.

However, he then describes how to proceed with estimating the probability of an event occurring in situations where we have limited (or indeed no) prior knowledge about what that probability might be.

“On trouve ainsi qu’un événement étant arrivé de suite un nombre quelconque de fois , la probabilité qu’il arrivera encore la fois suivante est égale à ce nombre augmenté de l’unité, divisé par le même nombre augmenté de deux unités.”

Which translates in English: “So, one finds for a event which has occurred any number of times until now, the probability it will occur again the next time is equal to this number increased by one, divided by the same number increased by two”.

Or, in math notation:

That is, given s successes out of n trials, the probability of success on the next trial is approximately (s+1)/(n+2).

To make his point, Laplace doesn’t hold back:

“… par exemple, remonter la plus ancienne époque de l’histoire à cinq mille ans, ou à 1,826,213 jours, et le soleil s’étant levé constamment dans cet intervalle, à chaque révolution de vingtquatre heures, il y a 1,826,214 à parier contre un qu’il se lèvera encore demain”

Which translates as: “…for example, given the sun has risen every day for the last 5000 years — or 1,826,213 days — the probability it will rise tomorrow is 1,826,214 / 1,826,215”.

At 99.9%, that’s a pretty certain bet. And it only becomes more certain each day the sun continues to rise.

Yet Laplace acknowledges that, for someone who understands the mechanism by which the sun rises and sees no reason why it should cease to function, even this probability is unreasonably low.

And it turns out that this qualification is perhaps just as important as the actual rule itself. After all, it hints at the fact that our prior knowledge of a system is encoded in the assumptions we make when assigning probabilities to each of its potential outcomes.

This is true in machine learning today, especially when we try learning from limited or incomplete training data.

But what is the rationale behind Laplace’s rule of succession, and how does it live on in some of today’s most popular machine learning algorithms?

Nothing is impossible?

To better understand the significance of Laplace’s rule, we need to consider what it means to have very little prior knowledge about a system.

Say you have one of Laplace’s urns, which you know to contain at least one red ball. You know nothing else about the contents of the urn “system”. Perhaps it contains many different colors, perhaps it only contains that one red ball.

Draw one ball from the urn. You know the probability that it will be red is greater than zero, and either less than or equal to one.

But, as you don’t know whether the urn contains other colors, you cannot say the probability of drawing red certainly equals one. You simply cannot rule out any other possibility.

So, how do you estimate the probability of drawing a red ball from the urn?

Well, according to Laplace’s rule of succession, you can model drawing a ball from the urn as a Bernoulli trial with two possible outcomes: “red” and “not-red”.

Before we’ve drawn anything from the urn, we’ve already allowed for two potential outcomes to exist. In so doing, we’ve effectively “pseudo-counted” two imaginary draws from the urn, observing each outcome once.

This gives each outcome (“red” and “not-red”) a probability of 1/2.

As the number of draws from the urn increases, the effect of these pseudo-counts becomes less and less important. If the first ball drawn is red, you update the probability of the next one being red to (1+1)/(1+2) = 2/3.

If the next ball is red, the probability updates to 3/4. If you keep drawing red, the probability reaches ever closer to 1.

In today’s language, probability concerns a sample space. This is a mathematical set of all possible outcomes for a given “experiment” (a process that selects one of the outcomes).

Probability was put on a formal axiomatic basis by Andrey Kolmogorov in the 1930s. Kolmogorov’s axioms make it easy to prove that a sample space must contain at least one element.

Kolmogorov also defines probability as a measure that returns a real valued number between zero and one for all elements of the sample space.

Naturally, probability makes a useful way to model real world systems, especially when you assume complete knowledge about the contents of the sample space.

But when we don’t understand the system at hand, we don’t know the sample space — apart from that it must contain at least one element. This is a common starting point in many machine learning contexts. We have to learn the contents of the sample space as we go.

Therefore, we ought to allow the sample space to contain at least one extra, catch-all element — or, if you like, the “unknown unknown”. Laplace’s rule of succession tells us to assign the “unknown unknown” a probability of 1/n_+_2, after n repeated observations of known events.

Although in many cases it is convenient to ignore the possibility of unknown unknowns, there are epistemological grounds for always allowing such eventualities to exist.

One such argument is known as Cromwell’s Rule, coined by the late Dennis Lindley. Quoting the 17th century’s Oliver Cromwell:

“I beseech you, in the bowels of Christ, think it possible that you may be mistaken”

This rather dramatic statement asks us to allow a remote possibility for the unexpected to occur. In the language of Bayesian probability, this amounts to requiring us to always consider a non-zero prior.

Because if your prior probability is set to zero, no amount of evidence will ever convince you otherwise. After all, even the strongest evidence to the contrary will still yield a posterior probability of zero, when multiplied by zero.

Objections, and a defence of Laplace

It may come as little surprise to learn that Laplace’s sunrise example attracted much criticism from his contemporaries.

People objected to the perceived simplicity — naivety, even — of Laplace’s assumptions. The idea that there was a 1/1,826,215 probability the sun would not rise the following day seemed absurd.

It is tempting to believe that, given a large number of trials, a non-zero probability event must happen. And therefore, observing so many consecutive sunrises without a single failure surely implies Laplace’s estimate is an overestimate?

For example, you might expect that after a million trials, you’d have observed a one-in-a-million event — almost guaranteed by definition! What’s the probability of doing otherwise?

Well, you wouldn’t be astonished if you tossed a fair coin twice without landing heads. Nor would it be cause for concern if you rolled a die six times, and never saw the number six. These are events with probability 1/2 and 1/6 respectively, but that absolutely does not guarantee their occurrence in the first two and six trials.

A result attributed to Bernoulli back in the 17th Century finds the limit as the probability 1/n and number of trials n grow very large:

Although on average you will have observed at least one occurrence of an event with probability 1/n after n trials, there is still a greater than 1/3 chance you will not.

Likewise, if the true probability of the sun failing to rise were indeed 1/1,826,215, then we perhaps shouldn’t be so surprised such an occurrence has never been recorded in history.

And, arguably, Laplace’s qualification is too generous.

It is true that, for a person who claims to understand the mechanism by which the sun rises every day, the probability of it failing to do so must be much closer to zero.

Yet to assume an understanding of such a mechanism requires us to possess prior knowledge of the system, beyond that which we have observed. This is because such a mechanism is implicitly assumed constant — in other words, true for all time.

This assumption lets us, in a sense, “conjure up” an unlimited number of observations — on top of those we have actually observed. It’s an assumption called for by none other than Isaac Newton, at the beginning of the third book in his famous “Philosophiae Naturalis Principia Mathematica”.

Newton outlines four “Rules of Reasoning in Philosophy”. The fourth rule claims we can regard propositions derived from previous observations as “very nearly true”, until contradicted by future observations.

“In experimental philosophy we are to look upon propositions collected by general induction from phenomena as accurately or very nearly true”

Such an assumption was crucial for the scientific revolution, despite being a kick in the teeth for philosophers such as David Hume, who famously argued for the problem of induction.

It is this epistemological compromise that lets us do useful science and, in turn, invent technology. Somewhere along the line, as we see the estimated probability of the sun failing to rise diminish ever closer to zero, we allow ourselves to “round down” and claim a fully fledged scientific truth.

But all of this presumably lies beyond the scope of the point Laplace originally sought to make.

Indeed, his choice of a sunrise example is unfortunate. The rule of succession really comes into its own when applied to completely unknown “black-box” systems for which we have zero (or very few) observations.

This is because the rule of succession offers an early example of a non-informative prior.

How to assume as little as possible

Bayesian probability is a keystone concept in modern machine learning. Algorithms such as Naive Bayes classification, Expectation Maximisation, Variational Inference and Markov Chain Monte Carlo are amongst the most popular in use today.

Bayesian probability generally refers to an interpretation of probability where you update your (often subjective) belief in the light of new evidence.

Two key concepts are prior and posterior probabilities.

Posterior probabilities are those we ascribe to after updating our beliefs in the face of new evidence.

Prior probabilities (or ‘priors’) are those we hold to be true before seeing new evidence.

Data scientists are interested in how we assign prior probabilities to events in the absence of any previous knowledge at all. This is a typical starting point for many problems in machine learning and predictive analytics.

Priors can be informative, in the sense they come with “opinions” about the probability of different events. These “opinions” can be strong or weak, and are usually based on past observations or otherwise reasonable assumptions. These are invaluable in situations where we want to train our machine learning model quickly.

However, priors can also be non-informative. This means they assume as little as possible about the respective probabilities of an event. These are useful in situations where we want our machine learning model to learn from a blank state.

So we must ask: how do you measure how “informative” a prior probability distribution is?

Information theory provides an answer. This is a branch of mathematics that concerns how information is measured and communicated.

Information can be thought of in terms of certainty, or a lack thereof.

After all, in an everyday sense, the more information you have about some event, the more certain you are about its outcome. Less information equates to less certainty. This means that information theory and probability theory are inextricably linked.

Information entropy is a fundamental concept in information theory. It serves as a measure of the uncertainty inherent to a given probability distribution. A probability distribution with high entropy is one for which the outcome is more uncertain.

Perhaps intuitively, you can reason that a uniform probability distribution — a distribution for which each event is equally likely — has the highest possible entropy. For example, if you flipped a fair coin and a biased coin, which outcome would you be least certain about?

Information entropy provides a formal means of quantifying this, and if you know some calculus, you can check out the proof here.

So the uniform distribution is, in a very real sense, the least informative distribution possible. And for that reason, it makes an obvious choice for an uninformative prior.

Perhaps you’ve spotted how Laplace’s rule of succession effectively amounts to using a uniform prior? By adding one success and one failure before we’ve even observed any outcomes, we’re using a uniform probability distribution to represent our “prior” belief about the system.

Then, as we observe more and more outcomes, the weight of the evidence increasingly overpowers the prior.

Case study: Naive Bayes classification

Today, Laplace’s rule of succession is generalised to additive smoothing and pseudo-counting.

These are techniques which allow us to use non-zero probabilities for events not observed in training data. This is an essential part of how machine learning algorithms are able to generalize when faced with inputs not seen previously.

For instance, take Naive Bayes classification.

This is a simple yet effective algorithm that can classify textual and other suitably tokenized data, using Bayes’ theorem.

The algorithm is trained on a corpus of pre-classified data, in which each document consists of a set of words or “features”. The algorithm begins by estimating the probability of each feature, given a certain class.

Using Bayes’ theorem (and some very naive assumptions about feature independence), the algorithm can then approximate the relative probabilities of each class, given the features observed in a previously unseen document.

The best estimate is the class, k, which maximizes the likelihood of observing the individual features, x, within a given document

An important step in Naive Bayes classification is estimating the probability of a feature being observed within a given class. This can be done by calculating the frequency at which the feature is observed in each of that class’s records in the training data.

For instance, the word “Python” might appear in 12% of all documents classed as “programming”, compared to 1% of all documents classed as “start-up”. The word “learn” might appear in 10% of programming documents and 20% of all start-up documents.

Take the sentence “learn Python”.

Using these frequencies, we find the probability of the sentence being classed as “programming” equals 0.12 ×0.10 = 0.012, and the probability of it being classed as “start-up” is 0.01×0.20 = 0.002.

Therefore, “programming” is the more likely of these two classes.

But this frequency-based approach runs into trouble whenever we consider a feature which never occurs in a given class. This would mean it has a frequency of zero.

Naive Bayes classification requires us to multiply probabilities, but multiplying anything by zero will, of course, always yield zero.

So, what happens if a previously unseen document does contain a word never observed in a given class in the training data? That class will be deemed impossible — no matter how frequently every other word in the document occurs in that class.

Additive smoothing

An approach called additive smoothing offers a solution. Instead of allowing for zero frequencies, we add a small constant to the numerator. This prevents unseen class/feature combinations from derailing the classifier.

When this constant equals one, additive smoothing is the same as applying Laplace’s rule of succession.

As well as Naive Bayes classification, additive smoothing is used in other probabilistic machine learning contexts. Examples include problems in language modelling, neural networks, and hidden Markov models.

In mathematical terms, additive smoothing amounts to using a beta distribution as a conjugate prior for carrying out Bayesian inference with binomial and geometric distributions.

The beta distribution is a family of probability distributions defined over the interval [0,1]. It takes two shape parameters, α and β. Laplace’s rule of succession corresponds to setting α = 1 and β = 1.

As discussed above, the beta(1,1) distribution is the one for which information entropy is maximised. However, there are alternative priors for cases in which the assumption of one success and one failure are not valid.

For instance, Haldane’s prior is defined as a beta(0,0) distribution. It applies in cases when we are not even sure if we can allow for a binary outcome. Haldane’s prior places an infinite amount of “weight” on zero and one.

Jeffrey’s prior, the beta(0.5, 0.5) distribution, is another non-informative prior. It has the helpful property that it remains invariant under reparameterization. Its derivation is beyond the scope of this article, but if you are interested, check out this thread.

The legacy of ideas

Personally, I find it fascinating how some of the earliest ideas in probability and statistics have survived years of contention, and still find widespread use in modern machine learning.

It is extraordinary to realise that the influence of ideas developed more than two centuries ago is still being felt today. Machine learning and data science have gained real mainstream momentum in the last decade or so. But the foundations upon which they are built were laid long before the first computers were even close to realization.

It’s no coincidence that such ideas border on the philosophy of knowledge. This becomes especially relevant as machines become more and more intelligent. At what point might the focus shift onto our philosophy of consciousness?

Finally, what would Laplace and his contemporaries make of machine learning today? It’s tempting to suggest they’d be astounded by the progress that’s been made.

But that would probably be a disservice to their foresight. After all, the French philosopher René Descartes had written of a mechanistic philosophy back in the 17th Century. Describing a hypothetical machine:

“Je désire que vous considériez … toutes les fonctions que j’ai attribuées à cette machine, comme … la réception de la lumière, des sons, des odeurs, des goûts … l’empreinte de ces idées dans la mémoire … et enfin les mouvements extérieurs … qu’ils imitent le plus parfaitement possible ceux d’un vrai homme … considériez que ces fonctions … de la seule disposition de ses organes, ni plus ni moins que font les mouvements d’une horloge … de celle de ses contrepoids et de ses roues”

Which translates as: “I desire that you consider that all the functions I’ve attributed to this machine such as… the reception of light, sound, smell and taste… the imprint of these ideas in the memory… and finally the external movements which imitate as perfectly as possible those of a true human…Consider that these functions are only under the control of the organs, no more or less than the movements of a clock are to its counterweights and wheels”

The passage above describes a hypothetical machine capable of responding to stimuli and behaving like a “true human”. It was published in Descartes’ 1664 work “Traité de l’homme” — a full 150 years before Laplace’s “Essai philosophique sur les probabilités”.

Indeed, the 18th and early 19th Centuries saw the construction of incredibly sophisticated automata by inventors such as Pierre Jaquet-Droz and Henri Maillardet. These clockwork androids could be “programmed” to write, draw, and play music.

_Drawing produced by one of Henri Maillardet’s early 19th Century automata ([video](https://www.youtube.com/watch?v=LCNQvm61_78" rel="noopener" target="blank" title="))

So there is no doubting that Laplace and his contemporaries could conceive of the notion of an intelligent machine. And it surely would not have escaped their notice how progress made in the field of probability might be applied to machine intelligence.

Right at the beginning of “Essai philosophique”, Laplace writes of a hypothetical super-intelligence, retrospectively named “Laplace’s Demon”:

“Une intelligence qui, pour un instant donné, connaîtrait toutes les forces dont la nature est animée, et la situation respective des êtres qui la composent, si d’ailleurs elle était assez vaste pour sou- mettre ces données à l’analyse … rien ne serait incertain pour elle, et l’avenir comme le passé, serait présent à ses yeux”

Which translates as: “An intelligence, which in a given moment, knows all the forces by which nature is animated, and the respective situation of the beings which compose it, and if it were large enough to submit these data to analysis … nothing would be uncertain to it, and the future as the past, would be present in its eyes”.

Could Laplace’s Demon be realized as one of Descartes’ intelligent machines? Modern sensibilities overwhelmingly suggest no.

Yet Laplace’s premise envisaged on a smaller scale may soon become a reality, thanks in no small part to his own pioneering work in the field of probability.

Meanwhile, the sun will (probably) continue to rise.

Once upon a time…

The beginning

In the good ol’ days of the 1950s when Elvis was ruling the charts with hits like Jailhouse Rock, a computing paradigm came out called mainframes a.k.a Big Iron (no relation to Arnold Schwarzenegger).

IBM was the main mover and shaker in this space, with a sprinkling of other small providers sometimes giving competition to Big Blue.

These early beasts were purely batch processing oriented — Mr John Appleseed could punch in his instructions(read programs) on a punch card (see below), pass it to the operations team, and go off for a coffee, or even leave for the day.

_By Arnold Reinhold — I took this picture of an artifact in my possession. The card was created in the late 1960s or early 1970s and has no copyright notice., CC BY-SA 2.5, [https://commons.wikimedia.org/w/index.php?curid=775153](https://commons.wikimedia.org/w/index.php?curid=775153" rel="noopener" target="blank" title=")

The operator would schedule and execute the previously submitted punch cards.

© MITRE Corporation

Fun fact: the above picture is of a HUGE 5Mb of of data on 62,500 punched cards. So just imagine the number of cards required to capture the code base of Win 10 or MacOS if we still used this technology!

Once the output was generated/printed, the operator would physically collect it and deposit the same to Mr. Appleseed’s cubicle or physical mailbox. Online access was primarily reserved for resources requiring it, like, say, staff at an airline’s booking counter.

So to all those crying in spite of having GUI-based IDEs to do their software development, if you think your job is hard — think of these pioneers.

Needless to say, the above process was not just slow but also extremely expensive. So much so that system usage was measured and charged in seconds towards the client’s account.

Code re-writes were extremely cumbersome and time-consuming. In fact, come to think of it, this may be the reason for the exceptionally good coding skills of the developers of that era, because as one Mr. Real slim shady has rightly said:

The PC Era

Next came the era of the PC, which was the democratization of technology in the form of the personal computer.

The processing model started moving from mainframe-based, centralized systems to the client-server-based model. Infrastructure planning, procurement, and maintenance became a vital part of software development, as the pace of business started to increase exponentially.

So it was not unusual to see software deployment on a client-server-based system accompanied by projections for future volume growth. Provisions had to be made for that. As it was, the typical engineer’s job was tough — but this also required him to be a soothsayer.

So now, our poor Mr. Appleseed had a lot of things to figure out. He not only had to figure out what the business teams were saying in the form of their requirements, but he also had to learn all the coding tools, standards, best practices, and innovations to follow.

He also had to take into account parameters like what the usage patterns of the software might be, how fast or slow it may grow in future, and what the optimum hardware may be so as to strike the right balance between performance and cost efficiency.

The bureaucratic hurdles in any given organization ensured that the hapless engineer was always stuck between the devil and the deep blue sea.

In addition to having sleepless nights over the ever-changing requirements and shifting deadlines, he also had to make do with the vagaries of infrastructure procurement. In the mainframe world, the situation was a bit better, as hardware procurement was not that commonly done. But resource allocation was still a chore, which led to a lot of heartburn.

The Cloud Era

The mid-2000s saw the advent of a new paradigm in computing: “the cloud.” It changed the nature of computing as it was known up to that point.

Before we delve deeper into it, let’s take a minute to refresh the definition of “the cloud” as given by National Institute of Standards and Technology (NIST):

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Five major attributes define a cloud based system viz-

a) On Demand self service

b) Broad network access

c) Resource pooling

d) Rapid elasticity

e) Measurement of service

The key enablers for this paradigm are:-

a) Fast WANs

b) powerful commodity servers

c) high performance visualization for commodity hardware

Our beloved Mr. Appleseed was now happy — after all, he was no longer at the mercy of his infrastructure engineer for getting servers or storage. He could, at the push of a button, get compute power, storage, a queue, and any other such service.

All was well in the computing world. But Mr. Appleseed, true to his human nature and being an enterprising species, started pondering how he could make his life easier.

Moreover, the world was becoming digital at a great pace with unheard-of scales of enterprises. This was making the practice of pre-allocating hardware a self defeating purpose. All the interactions with the digital world were becoming majorly event-driven.

Enter Serverless architecture

2015 (or some say 2012) was the time when this computing paradigm came into being. There have been a number of interpretations proposed for this term (serverless) and its implications.

One school of thought attributes it to Backend as a Service (BaaS). For example, authentication services offered by third party providers like Google or Facebook.

The other school of thought links it to a concept wherein applications with business (read: server side) logic are run over stateless containers, managed by a third party provider in its entirety, which is known as Function as a Service (Faas).

This article focuses on the second definition of the concept, as it has interesting implications for the way web applications are being architected.

The brief evolution of the cloud computing paradigm

At its core, FaaS is a simple concept which means that:

• The development team should not get worried over aspects like the backend server, its maintenance, procurement, or scaling (well, to an extent). All the team has to worry about is application logic.
• Processing is carried out on compute containers which are stateless. So in other words, after one logical unit of processing, there is no storage of the processing attributes by the system
• Instead of having a server with long running processes, say cron, here the processing is only initiated once the qualifying “event” occurs and is terminated when the processing is complete or the set time has elapsed (whichever happens earlier).

It does not mean that there are no servers anywhere in the whole scheme of things. All it means is that the servers and their maintenance is now hidden from the developer.

Also, since the physical unit of the compute is now a container, there is no need to have long running servers with event listeners running on them to carry out any processing. Qualified event sources could be plugged into the system and the service would take over.

What Serverless is NOT

“What’s in a name? That which we call a rose by any other name would smell as sweet”. — Juliet, Romeo and Juliet

As it is with any new innovation, more often than not glitzy names are used by vendors to re-package old wine in a new bottle, so to speak, to gain more eyeballs.

In case of serverless, this confusion is more wide-spread. This is because the concept has developed in a very short period of time and in very close proximity to the other concepts with which it can be confused.

So here I take a shot at trying to clarify what serverless usually is (or can be) confused with. I’ll also share my two cents.

It’s NOT a Container

“A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. Available for both Linux and Windows based apps, containerized software will always run the same, regardless of the environment. Containers isolate software from its surroundings, for example differences between development and staging environments and help reduce conflicts between teams running different software on the same infrastructure.” — Docker.com

The container is a recent innovation in computing. Google popularized it by running Gmail on it. Containers are useful for maintaining the reliability and homogeneity of software running across various computing environments.

For example, the code may have been developed in Java 8, but production may be on Java 9 — so the code which was running fine in dev may start throwing weird errors in production.

Roughly speaking, the container is the erstwhile VM (virtual machine) on steroids. It has none of the excess flab of individual OS versions. Unlike VMs, where there used to be a separate copy of the guest OS (thereby making the VM resource heavy), containers share the underlying OS kernel. This allows multiple containers to be run on that particular machine compared to VMs.

VM vs Container

VM vs Container

Containers remove one part of the problem: they provide a homogenous runtime production environment, albeit at the cost of increased maintenance effort.

However, to be fair, containers are typically better-placed for different kinds of work-load (like those that are inherently more complex). So they find favor in enterprise IT landscapes where there is already a monolith up and running and the organization may be wanting to port it quickly to the cloud.

Horizontal scaling is a vector wherein serverless steals the show over containers. Modern cloud vendors “theoretically” provide unlimited scaling capability for their serverless offerings. And best of all, this scaling is totally transparent to the user.

Serverless computing is better aligned to event-driven, asynchronous operations, while containers appear to be better aligned to the synchronous REQ/RESP workloads.

But given the pace at which things are changing, the differences can get diluted to a great extent over a short period of time.

It’s NOT PaaS

“Platform as a service” (PaaS) is a cloud computing model in which a thirdparty provider delivers hardware and software tools — usually those needed for application development — to users over the internet. A PaaS provider hosts the hardware and software on its own infrastructure. As a result, PaaS frees users from having to install in-house hardware and software to develop or run a new application.” — Techtarget

Just like containers , PaaS also differs mainly concerning the vector of scaling. However hands off the PaaS vendors may claim their offering is, it still requires some admin maintenance effort, unlike serverless.

With PaaS, there is always a minimum running footprint in the system which will be up and incurring costs. However with serverless, it can be brought down to absolute zero.

PaaS may still be a good choice given its more advanced ecosystem and tooling and language support. However this should not be a show-stopper given the high pace of advancements in the field of serverless.

Real programmers don’t use PASCAL

Programmers today build distributed applications and artificial neural networks. They use functional reactive programming, open source web frameworks, and serverless environments. Yet, impostor syndrome is real, and programmers still criticize each other for not being “real programmers.”

I worked as a docent for the Computer History Museum for years. The trope of a “real programmer” has been around since the beginning of software. And I can prove it with a story.

The story starts with a 1983 letter, Real Programmers Don’t Use PASCAL, written by Ed Post. The letter was published in Datamation, and discussed the “macho” side of programming. It needled those who disparage higher-level language users as not “real programmers.”

The Story of Mel is an online response to that letter. It was posted to Usenet on May 21, 1983 by Ed Nather.

Mel and Ed were colleagues at a typewriter company that had branched out into building computers. Their breakout success was the LGP-30: a drum memory computer with a Flexowriter keyboard and paper tape reader. (The header image in this article is the dashboard of an LGP-30.) Mel was assigned to rewrite a popular program for the successor computer, the RPC-4000.

Port? What does that mean?

After Mel left the company, Ed was tasked to rewrite part of this program. In the story, he discovers an infinite loop in the code, which somehow doesn’t prevent the program from functioning:

Perhaps my greatest shock came when I found an innocent loop that had no test in it.
No test. None.
Common sense said it had to be a closed loop, where the program would circle, forever, endlessly.
Program control passed right through it, however, and safely out the other side.

Ed discovered that the closed loop was causing an overflow, that rewrote the instruction code. The outcome of the overflow was a jump instruction, moving control of the program to a different memory location.

It’s a great story. But does it check out?

Forensic code analysis: Does the story check out?

Our first step is to look for technical details of the machine the program was written for. While the story makes extensive mention of the LGP-30, the program was actually running on an RPC-4000. (Remember, it needed to be re-written for this new machine.)

Both machines used drum memory for program storage. (Fun fact: the rough equivalent of your modern hard drive was drum memory, paper tape, punch cards or magnetic tape!) A single line of electromagnetic heads would read/write data as the drum spun at a constant velocity underneath them. Here is a visual reference:

_Memory drum diagram. Source: [RPC-4000 Manual](https://archive.org/details/bitsavers_royalPrecirogrammingManual_8537458" rel="noopener" target="blank" title=")

Data was stored and retrieved from the various sectors and tracks of the drum. To find out more about the format of the data, we can consult the RPC-4000 programming manual, which archive.org has scanned and preserved online.

On page 20 of the manual, we find the following data word diagram:

RPC-4000 Word Format Diagrams

The command word breaks down into:

• 5 bits for the command
• 13 bits for the track/sector location of the operand
• 13 bits for the track/sector of the next command’s address

Bit 31 is the index tag which, when set, activated the index register:

[The index register] allowed the programmer to write a program loop that used an indexed instruction inside; each time through, the number in the index register was added to the address of that instruction, so it would refer to the next datum in a series.

The story mentions that the “index bit” is _“the bit that lay between the address and the operation code in the instruction word.”_ Yet, the diagram above shows that the index tag bit is actually at bit 31, past the command and addresses. Personally, I chalk this up to a mis-remembering by the author in the years between when he reviewed the code and when the story was recorded.

Luckily, this doesn’t affect the overflow aspect of the story. Since the instruction word was being pulled into memory and incremented, the index bit would still need to be set on in order for the increment to overflow the Next Address.

To re-create the instruction words in the loop, we need to know more about how the program operated. Here is a quote from the critical part of the story:

He had located the data he was working on near the top of memory —
the largest locations the instructions could address —
so, after the last datum was handled, incrementing the instruction address would make it overflow.
The carry would add one to the operation code, changing it to the next one in the instruction set: a jump instruction.
Sure enough, the next program instruction was in address location zero, and the program went happily on its way.

Hypothetical implementation: “Show me the bits!”

Here is a potential instruction that may be the jump instruction referenced in the story:

We can see the command bits are 10111. If Branch Control is off, “the next instruction is that specified in the Next-address field.” So one hypothetical situation would be that, after the overflow, the register (using pipes to denote separations between bitfields) read:

10111 | 0000000| 0000000 | 0

Extrapolating back, prior to the increment and overflow, the register would have read:

10110 | 1111111 | 1111111 | 1

One interesting side effect of working through this implementation is that the instruction used doesn’t really matter. Each instruction in the RPC-4000 includes the address of the next instruction. An overflow in the index bit into the next address field will result in a jump to that address irrespective of the command bits.

Epilogue

Group photo from the August 1956 Librazette

Mel Kaye (pictured standing, rightmost) continued working and eventually retired. A fan named Anthony Cuozzo posted in 2014 that he tried to get into contact with Mel:

I did eventually manage to get in contact with Mel, but I scared him away, unfortunately. That’s a story for another day… :-/ (source)

Out of respect for Mel’s privacy, I won’t post any personal information, and stick to the program and the story. If anybody knows how Mel feels about his internet fame, I’d love to hear from you.

I haven’t kept in touch with Mel, so I don’t know if he ever gave in to the flood of change that has washed over programming techniques since those long-gone days. I like to think he didn’t. — Ed Nather

Further sources:

• Wikipedia’s page on the Story of Mel
• Mel’s manual for the RPC-4000 blackjack game
• The Truth Never Gets in the way of a Good Story by Jan Howard Brunvand

Dave works developer relations at IBM. For some reason, IBM does not have an SDK for the RPC-4000.

Since March of 2017, I have been enriching my understanding of design through mathematics — specifically, ancient geometry. As you scroll down, I hope my findings will be enriching for you too!

I provide three demonstrations to explain how theorems from ancient mathematics can help you improve your design skills.

To begin with, theorems from ancient mathematics can be simple, beautiful, and artistic. Take, for example, an equilateral triangle. You only need two circles of the same size to make a perfect equilateral triangle.

_[1 vishalkumar.london](https://www.instagram.com/vishalkumar.london/" rel="noopener" target="blank" title=")

Draw the circle on the left. Then draw a straight line from the middle of that circle (A) to the end (B). Draw a circle exactly the same size on the right so that it passes through A. Then draw two straight lines from A and B to the intersection of the two circles (C).

Easy, right? Didn’t even need a calculator. It’s incredible to think that the red triangle above has sides that are all of the same length, with all inside angles being 60° — and we didn’t even need any numbers to make it!

“I never knew math could be so simple.”

This is the first theorem of a book entitled The Elements, written over 2,300 years ago by an Ancient Greek mathematician, Euclid. It has been estimated to be second only to the Bible in terms of the number of editions published since mechanical printing was invented in the 15th Century.

The Elements was so influential that Abraham Lincoln had a copy on his desk at all times. (Cool story).

Hold on, it gets better. Let’s take it up a level.

There are many mysteries to an equilateral triangle. The same red equilateral triangle you saw above can be used to generate a range of other shapes and forms.

Below we see that the equilateral triangle can help draw a circle, hexagon, rectangle, and a whole range of other polygons. See how many you can find.

2 vishalkumar.london

_Image taken from[ Jinju Jang](https://medium.com/@arle13/a-story-of-a-designer-conquering-mathematics-d0fd4585f0ba" rel="noopener" target="blank" title=") on Medium (left) and the first six books of the Elements of Euclid (right), by Oliver Byrne (1847)

Throughout history the equilateral triangle has been fundamental to human civilization, society and religion.

In his 2010 paper, Mysteries of the Equilateral Triangle, mathematician Brian McCartin explains how the shape has helped with a broad range of designs — from map-building, to problem-solving, to creating works of art and making religious symbols and relics.

Let’s look at architecture in Ancient Greece. The figure below (left) is very similar to my one above. It shows the facade of the Parthenon, built in 432 BC, together with superimposed concentric equilateral triangles, each successive triangle diminished in size by one-half. This diagram helps visualize the perfect and well-crafted proportions of the Parthenon.

It’s clear that the Greeks knew about the importance of geometry.

Image of the Parthenon (left) and image of Great Pyramid of Khufu
at Giza — Brian McCartin (2010)

Another, and older, common example of equilateral triangles used in architecture is the Pyramid Complex of Giza in Egypt. Each of the four triangular sides that form the pyramids are equilateral triangles. These are examples of the strength of the triangle in architecture as the pyramids have been standing for over 4,000 years.

Why is any of this important?

Taking a geometric approach to drawing basic, smooth shapes can set the foundations for improving one’s design skills.

A geometric approach allows you to organize and arrange your space in a much easier way — whether your space is a computer or mobile screen, your notebook, or even a post-it note.

Look at how Apple designed their logo. Inkbot Design challenges Apple’s logo, dissecting it and asking whether their logo was designed using the Golden Ratio.

_Image taken from [Inkbot](http://inkbotdesign.com/designing-logos-grid-system" rel="noopener" target="blank" title=")

Related story: Jinju Jang also explains how she used mathematics and geometry to improve her design skills.

So far the equilateral triangle has been the star of my story, but it is only the first of many interesting characters and protagonists.

Euclidean geometry is the classic geometry we learn at school to make shapes with ‘smooth’ edges, such as a triangle or circle. Euclidean geometry proceeds logically from axioms, to theorems and then to three-dimensional space.

If you add in a ‘time’ dimension you get Newtonian physics, forming a single space-time continuum.

[Kroneker Wallis, a minimalist production team in Barcelona, have even created contemporary designed books that explain precisely this in more detail! This also validates my point about ancient mathematics being important for design today — so, support them on Kickstarter!]

Euclid’s Elements (left) and Newton’s Principia (right) by Kroneker Wallis in Barcelona

“I never knew math could be so artistic!”

However, there are adaptations of geometry to make infinitely complex shapes with ‘rough’ edges and across multiple dimensions in addition to space and time: design materials based on biological or environmental properties, for example.

Enter fractal geometry.

Fractal geometry is used across the natural sciences — mathematics, physics, chemistry and biology — but more recently, for building and urban design. For example, Neri Oxman at the MIT Media lab computationally simulates fractal forms from nature to design and generate new materials and buildings (see below).

Moreover, Michael Batty from the Centre for Advanced Spatial Analysis at the Bartlett, UCL, explains that fractal geometry has much to do with the way cities evolve. His research computationally simulates the evolutionary process to suggest “good” urban design as opposed to “bad” urban design.

Silk Pavilion designed by Neri Oxman using fractal geometry (and more!)

Fractal geometry is a field of mathematics born in the 1970s and mainly developed by Benoit Mandelbrot. It can lead to self-similar forms across different scales, in this way evoking natural growth and design — the beautiful image below is a nested Apollonian gasket.

The theory of fractals can also be linked to complexity theory and chaos theory — please look at the bottom left of Dominic Walliman’s Map of Mathematics poster.

3 vishalkumar.london

Right, I promised that this post was not going to get boring, so I am going to stop here. (I hope it has been enriching!)

Conclusion

I would like to highlight two major points made in this article:

1. Simple ideas from geometry and mathematics can be helpful and profound for those interested in all spectrums of design. Matej Latin describes how he used geometry to get a pixel perfect User Interface element for his project.
2. It is possible to use more complex strands of geometry to create much more interesting shapes. For example, generating designs similar to natural forms.

I will continue to explore and explain how mathematics can help us understand design at a much deeper level. This first post was mainly about geometry, but I hope to also look at other fundamental ideas from algebra, calculus and trigonometry.

Thank you for reading!

Before you leave…

If you found this article helpful, hit the? button below and share the article on Facebook, Twitter or LinkedIn so that everyone can benefit from it too.

See more of Vishal’s work on Instagram @vishalkumar.london or on his website.

Artificial Intelligence is moving fast. The vibe is all around. Facts are beginning to sound like science fiction movies and science fiction movies like a version of reality (with better graphics). It may be that AI has finally achieved the level of maturity it has been pursuing for decades and was stubbornly denied, making parts of its community, and the whole world, suspicious against its feasibility.

Frankenstein may contain parallels relevant to the present day. Mary Shelley’s Gothic novel contains a discussion on the consequences of creating and introducing an artificial being into society. The Creature puzzles us with its inhuman atrocity and yet human manifestations of weakness, need for companionship and existential crisis.

One could say that we should focus on the future and the consequences of our discoveries. But how can one focus on the chaos created by injecting an army of Creatures into a system so complicated as contemporary society? One could also focus on the achievements, the success-stories that made these ideas sound veracious. But how can one ex post discriminate between correct intuition and luck?

It takes self-restraint, and wisdom, to set aside for a while the branches of your work and evaluate the firmness of its roots. A blooming tree can be distracting.

Whether you are tracing the rules of logical thinking in the ancient Greek philosophers, the formulation of reasoning in Arabic mathematicians or the power of mathematical knowledge in 19th century intellectuals — one unsettling notion becomes clear: the questions are deeper than the networks you can design (even taking Moore’s law into account).

“I believe that what we become depends on what our fathers teach us at odd moments, when they aren’t trying to teach us. We are formed by little scraps of wisdom.”

Umberto Eco

The rest of the discussion will emerge from the history of AI. Not the history of achievements, but the history of questions, arguments and beliefs of some significant individuals. Most of the events revolve around the ‘60s, the era AI acquired its official definition, its purpose, its scientific community and its opponents.

Can machines think?

In 1950 Alan Turing attempts to answer this purposely simplistically-expressed, question in his seminal paper Computing Machinery and Intelligence. Acknowledging its ambiguity and the limits it imposes on understanding AI, he proceeds by formulating a thought-experiment, also known as the Turing test:

Player A is a man, player B is a woman and player C is of either sex. C plays the role of the interrogator and is unable to see either player, but can communicate with them by means of impersonal notes. By asking questions to A and B, C tries to determine which of the two is the man and which is the woman. A’s role is to trick the interrogator into making the wrong decision, while B attempts to assist the interrogator in making the right one.

The reformulated question is then:

What will happen when a machine takes the part of A in this game? Will the interrogator decide wrongly as often as he does when the game is played between two humans?

Turing’s approach seems to follow the doctrine of the duck test: If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

His attitude when it comes to “human” aspects of intelligence, such as consciousness, is that you can’t blame someone (or something) for not possessing a characteristic that you have yet to define. Thus, consciousness is irrelevant in our quest for AI.

Gödel’s incompleteness theorems were an obstacle in one’s attempt to talk about AI. According to them mathematical logic cannot be both complete and consistent, thus, machines equipped with mathematical logic to learn, as is the case of AI, are expected to fail in learning some truths. Turing’s answer to this is fairly disarming: how do you know that human-intellect does not also come with its limitations?

Turing’s paper is lavish both in terms of arguments and a clear, dialectical structure, nevertheless constrained in speculations about technologies that had yet to be discovered.

Steps towards artificial intelligence

Marvin Minsky was one of the fathers of AI as a research field. In the dusty album of AI family photos, Minsky would be this old man that brings some uneasiness to a family dinner: “Old uncle Minsky. He was charmingly peculiar and always had something interesting to say”.

Minsky was one of the organisers of the Dartmouth Conference in 1956, where Artificial Intelligence was first defined as a term and a field. He is mostly remembered for his vigour of believing that AI is feasible and his depreciation in pursuing it with wrong means.

Let’s see what Minsky had to say in 1961, when he was asked about the so far progress in AI.

Should we ask what intelligence “really is”? My own view is that this is more of an aesthetic question, or one of sense of dignity, than a technical matter! To me “intelligence” seems to denote little more than the complex of performances which we happen to respect, but do not understand. So it is, usually, with the question of “depth” in mathematics. Once the proof of a theorem is really understood, its content seems to become trivial.

Acknowledging the inherent difficulties in defining AI, and thus pursuing it, Minsky begins by setting the building pillars of it. According to him, these are search, pattern-recognition, learning, planning, and induction.

If the ultimate purpose of the program is to search and find solutions of its own, then pattern-recognition can help it recognise the appropriate tools, learning can help it improve through experience, and planning can lead to more efficient exploration. As regards the possibility of making a machine with inductive abilities and thus reasoning, Minsky has to say:

Now [according to Gödel’s incompleteness theorem], there can be no system for inductive inference that will work well in all possible universes. But given a universe [our world], or an ensemble of universes, and a criterion of success, this (epistemological) problem for machines becomes technical rather than philosophical.

The rest of the text contains a recurrent urge to clarify that the pursuit of AI should be conducted through complex, hierarchical architectures. For this reason he questions the perceptron approach, as it will fail for moderately difficult problems. And frankly, we can’t expect reality to be simplistic.

Minsky can be attributed the responsibility of discouraging research in perceptrons, which probably delayed the bloom of deep learning. The realisation that, even using simple building blocks, one can solve complicated problems by going into deep architectures seems to have escaped his, nevertheless, ingenious insight.

Yet his remarks can be seen as ultimately constructive criticism, as they helped the community explore the weaknesses of the original approaches. Also, deep learning may be the best we have so far (and how marvellous the applications), but should not be regarded unconditionally as the Holy Grail of AI.

Minds, brains, and programs

In 1980 John Searle got angry. Although he probably got angry earlier, this is the moment he decided to publicise his disagreement with strong AI. Indeed, even the title sounds sarcastic. I feel like Searle is grabbing me by the collar and, vigorously waving his finger, saying: “Let me help you make some fundamental distinctions young lad”.

“One gets the impression that people in AI who write this sort of thing think they can get away with it because they don’t really take it seriously, and they don’t think anyone else will either. I propose for a moment at least, to take it seriously.”

Searle is solely attacking the notion of strong AI, which he identifies as the capability of a computer to practice any human-like behaviour. He translates this to the ability of a machine to demonstrate consciousness which he disproves by analogy. His famous thought-experiment, the Chinese room, goes like this:

You are a monolingual English speaker locked in a room with the following things: a large batch of Chinese writing (called a script), another large batch of Chinese writing (called a story) and a set of English rules instructing you how to match Chinese symbols of the second batch to the first (called a program). Then, you are given another batch of Chinese writing (this time called questions) and another set of English instructions with rules that match the questions to the other two batches. Congratulations, you just learned Chinese!

This is the Chinese Room experiment, introduced by Searle in 1980 . A thought experiment is not an experiment per se, as its goal is not be conducted, but to explore the potential consequences of an idea. The oldest and most famous is, probably, Galileo’s Leaning Tower of Pisa experiment (did you also think Galileo was actually dropping apples from the tower?).

Searle’s point is that the fact that you can produce Chinese answers by accepting Chinese questions does not mean that you understand Chinese, if this ability was created by following rules in another language. As a consequence, a machine that gives the expected output after it has been given the appropriate algorithm should not be considered a ‘thinking’ entity.

What Searle does not dispute is the ability of a program to think, as in terms of some functional reasoning. He accuses current AI researchers of being behaviouristic and operationalistic, as they attempt to equate a program with a mind (which is true), letting aside however the importance of the brain.

According to him consciousness comes only from biological operations and since a program is totally independent from its implementation (as it can run on any hardware) it cannot exhibit consciousness.

Reading the original text, one gets the feeling that he is attacking an immature community of computer scientists that has not bothered to reach a consensus on what intelligence is, nevertheless attempts to simulate it guided by teleological approaches and speculations.

Minsky’s response to Searle, and philosophical approaches in general, is as nihilistic as it gets: “they misunderstand, and should be ignored”.

Elephants don’t play chess.

And you should not make them feel bad about it. This paper, written by Rodney A. Brooks in 1990, is an attempt of a Nouvelle AI evangelist to persuade, employing both arguments and his robotic fleet, that the classical approach to AI should leave some space for his.

To get the feeling of that era, AI was experiencing its second winter. Funding was cut as companies and governments realised that the community had set the expectations too high.

So, time for introspection. When something fundamentally fails, there are two ways to go at it: either it’s impossible to achieve or your approach is flawed.

Brooks suggested that AI’s stagnation is due to its dogma of functional representations. The symbol system hypothesis is a long-standing view on how intelligence operates. According to it, the world involves entities, like people, cars and cosmic love, so it is natural to match them to symbols and feed machines with them. If this hypothesis is correct, then you have provided the machine with all the necessary information for it to “come up” with intelligence.

Although this assumption does not seem problematic, it has some far-reaching consequences that might account for the bad performance of AI:

• The symbol system is not adequate to describe the world. According to the frame problem it is a logical fallacy to assume anything that is not explicitly stated. To this point, Brooks charmingly suggests: why not take the world as its own model?
• Intelligence cannot emerge from simple calculations. The immense use of heuristics, that are necessary to train intelligent algorithms is a contradiction to our attempt to create knowledge. (Your grid-search is insulting to human intellect.)
• AI’s obsession with ensuring generality of a learned model has lead to a phenomenon Brooks calls puzzlitis: excessive effort given on proving that the algorithm works in obscure cases. It ιs certainly an attractive ability, but it does not seem to be a fundamental consequence of knowledge and our world is rather consistent.

Brook’s counterproposal is the physical grounding hypothesis. That is, allow Artificial Intelligence to directly interact with the world and use it as its own representation. This certainly changes the standard practise of AI: from learning requiring immense computational resources, guidance from experts and a never-satisfied need for training data, Brook suggests equipping physical entities with cheap hardware and unleashing them in the world. But does this underestimate the problem?

Brooks sees intelligence rising from collective behaviour, not sophisticated parts. Perhaps the most profound observation of his experiments regards how “goal-directed behaviour emerges from the interactions of simpler non goal-directed behaviours”. There does not need to exist a predetermined coordination pattern, as an intelligent machine should draw its own strategies to optimally interact with the world.

Brook’s argument of evolution draws a long way along persuading us of the importance of the physical ground hypothesis: humans are the most common and closest example we have to intelligence. Thus, in our attempt to re-create this characteristic, isn’t it natural to observe the evolution, a slow, adaptive process that gradually led to the formulation of human civilisation? Now, if one considers the time it took us to evolve skills such as interacting, reproducing and surviving, in contrast to our still young abilities of using a language or playing chess, then one may reach the conclusion that these are the hardest skills to develop. So, why not focus on that?

Although ecstatic about the practicality of his approach, Brook acknowledges its theoretical limitations, which can be attributed to the fact that we have yet to develop a complete understanding of the dynamics of interacting populations. Once more, the disregard of an engineer towards philosophical objections is evident:

“At least if our strategy does not convince the arm chair philosophers, our engineering approach will have radically changed the world we live in.”

AI manifests progress

Despite floating in a sea of questions, AI manifests something we cannot dispute: progress. Nevertheless, stripping current applications from the effect of technological advancements and heuristic advantages to acquire an accurate perception of the quality of the current research is a tedious task.

Will deep learning prove a worthy tool towards pleasing our ever-demanding criteria of intelligence? Or is this another interglacial period before AI reaches winter again?

What’s more, the concerns and questions have shifted from pure philosophical to social, as the consequences of AI in everyday life are becoming more obvious and pressing than the need for understanding consciousness, God and intelligence. Yet, this may be an even more difficult question to answer and urge us to dig even deeper.

When Wittgenstein wrote the Tractactus, he was confronted with the danger of a fundamental fallacy: his arguments fell victims to the doctrine of his work. That is, if one accepted his doctrine as true, his arguments were illogical and thus his doctrine should be false. But Wittgenstein thought differently:

“My propositions are elucidatory in this way: he who understands me finally recognises them as senseless, when he has climbed out through them, on them, over them.”

To understand the truth behind a complicated idea, we need to evolve. We must stand firm on our previous step and be willing to abandon it. Not every step has to be correct, but it has to be understood. When later confronted with this argument, Wittgenstein said that he does not need a ladder, as he is capable of directly approaching the truth.

We may still need it.

We have all experienced our awkward moments. Something unexpected happens, there is some social tense and a personal uneasiness and you would really like to get over it or forget that it ever happened. But what if you are a rigorous mathematician and you just got your world disproven?

Math has always been about the pursuit of understanding the world through logic and expressing it in a strictly defined, mathematical language. It is really indicative, educative, and fun, to observe mathematics when it stopped (momentarily) making sense.

1. The discovery of irrational numbers

The School of Athens, depicting, among almost every possible ancient Greek philosopher, Pythagoras in the left corner

As the origins of mathematical rigor lie in ancient Greece, mathematical thought started close to religious beliefs, thus numbers were attributed divine characteristics.

The School of Pythagoras, an occult team of early mathematicians that pushed mathematical knowledge forward, like all cults, was based on some fundamentalistic beliefs. Astonished by the applicability of ratios to every practical problem, they believed that ratios (yes, simple divided numbers) are divine, as they can explain anything that is happening in the world.

Accordingly, everything that is happening in the world should be able to be expressed as a ratio, right?

Now, imagine their surprise when they discovered the number square root of 2, while applying the newly formulated Pythagorean Theorem. This irrational number (irrational meaning that it cannot be expressed as the ratio of two numbers) defied world order as expressed by divinity of ratios and questioned their whole philosophy.

Terrified by the consequences of this revolutionary discovery, they decided not to tell anyone about it. It is also said, that they even drowned the man who did the discovery, Hippasus. Quiet scientific, don’t you think?

2. Infinity

The discovery of irrational numbers, being already bad as it was, brought the Greeks in front of a more terrifying discovery: infinity. As irrational numbers are characterized by having an infinite number of decimal digits, Greeks had to come up with an explanation for how a never-ending series of numbers can be created. The notion of infinity is difficult to understand today, let alone an age when religion was connected with science and a mathematical belief should not challenge our understanding of God. So, what did the Greeks do? Philosophers, like Aristotle and Plato, rejected the notion of an absolut infinity and mathematicians came up with inventive ways to circumvent the need for infinity in geometry, like Eudoxus of Cnidus who developed the method of exhaustion to calculate the area of shapes. It was not until the late 17th century that Newton and Leibniz encouraged taking infinity into account through their use of infinitesimals and John Wallis introduced the well-known symbol of infinity in 1655.

3. Zeno’s paradoxes

The Greeks certainly went to extremes when it came to philosophical reasoning.

After his predecessor Heraclitus claimed that everything in the world is constantly changing, Parmenides claimed that nothing changes. As a result, motion is a mere illusion and therefore, using mathematics, the language of truth according to the Greeks, to describe it should be impossible.

Zeno, one of Parmenides’ students, devised a series of paradoxes aimed to prove the irrationality of motion. The most famous one, Achilles and his tortoise, goes like this: Achilles is racing against a tortoise, which being significantly slower is given the advantage of starting the race 100 meters ahead of him.

If we assume, for the shake of simplicity, that the speeds of the two contestants are constant and Achilles is 10 times faster than the tortoise then we can say that when Achilles reaches the starting point of the tortoise, this will have run 10 meters. So, Achilles will try to catch up and by the time he reaches this next point, the tortoise will have moved an extra one meter.

This high-school math problem, being as simple and clear as it is, leads us to the following paradoxical conclusion: Achilles will never reach the tortoise no matter how much faster he is. Congratulations Zeno, you made motion sound illogical.

Zeno’s paradoxes were believed to exist in the realm of metaphysics and troubled philosophers and mathematicians for ages, but today they can be explained with calculus, a mathematical tool the Greeks did not possess. Let’s “move” on then.

4. Möbius strip

A make-it-yourself Möbius strip

The funny looking Möbius strip, which was also independently discovered in 1858 by the unlucky Listing whose name left the history of mathematics untouched, is a surface with only one side and only one boundary, often used to puzzle young math students.

You can easily create it by taking a strip of paper, twisting it and then joining the ends of the strip.

Being the first example of a surface without orientation it did not shake the grounds of mathematics as much as the other discoveries of this list did, yet it provided a lot of practical applications, such as a resistant belt, and inspired mathematicians to come up with unorientable surfaces, like the Klein bottle. (The name of this surface possibly comes from a double coincidence: Klein, its conceptor, originally named it Fläche, which means surface in German and sounds similar to Flasche, which means bottle. The fact that it also looked like a bottle seems to have sealed the renaming).

5. Cantor’s uncountability of real numbers

Dealing with infinity already being a drag, Cantor proved in 1874 that there are in fact different kinds of infinity. In particular, proving the uncountability of real numbers, Cantor proved that this set is bigger to the already infinite set of natural numbers.

In 1891, he also provided the diagonal argument, one proof so elegant that it was later adopted as a tool to prove through the use of a paradox. His remark gave birth to the theory of cardinal numbers, as well as paradoxes dealing with the question: how many infinities can you handle?

6. Russell’s paradox

_Bertrand Russell was a mathematician, philosopher, [social critic](https://en.wikipedia.org/wiki/Mathematical_logic" rel="noopener" target="_blank" title="Mathematical logic">logician, mathematician, historian, writer, <a href="https://en.wikipedia.org/wiki/Social_critic" rel="noopener" target="blank" title="Social critic), political activist and, to my opinion, a personality worth studying and inspiring oneself from.

In 1901 Russell discovered a weak spot in Cantor’s so-far well-established set theory, which led him to a contradiction the mathematical world could not oversee. According to this theory, any collection of things can be a set.

Russell’s contradictory example, also called the Barber’s paradox, goes as follows: imagine a town that has a special rule; every man that is not shaved by himself must be shaved by the barber of the town. The awkward question, which you can try to answer yourselves, is: who shaves the barber?

This discovery led him to questioning the mere foundations of the previous set theory and creating a new one, which being more complicated than the later proposed Zermelo-Fraenkel set theory, did not catch up.

7. Gödel’s incompleteness theorems

Kurt Gödel the logician, mathematician and philosopher that shook the grounds of mathematics and logic in the 19th century.

If the previous events seemed to create slightly uncomfortable moments, wait for the following awkward turtle (and this is worse than the one of Achilles).

We are talking about the 20th century. People did not just want to know. They wanted to know if it is possible to know, and prove it. Unluckily for them, and the human need for understanding the universe, Gödel published in 1931 two theorems, known as the incompleteness theorems.

Explaining the technicalities of them is as difficult as coming in terms with their conclusions, as what Gödel proved was that, considering a consistent and complete system, such as the language of arithmetic, there are statements that are both true and cannot be proven. He illustrated the truth of his theorem with this simple statement, inspired by the liar’s paradox: “This statement cannot be proven”. If this is true, then this statement is true and cannot be proven. If this is false, then this statement can be proven, which contradicts to the original argument that it cannot be proven.

These were very bad news for mathematics, depriving them of their original glare of explaining the absolute truth. It was also a terrible comeback to Hilbert’s quest for knowledge, expressed in his statement “We must know, we will know”.

8. Tarski’s undefinability theorem

It seems that Tarski was inspired by the despair created by Gödel. In 1936 he provided proof for the undefinability problem.

Although the observations made by Tarski are also included in Gödel’s work, it is argued that Tarski’s work has a more profound philosophical impact. Tarski managed to reach the general conclusion that a language cannot define truth in itself. Although this is an important limitation, he suggests that using a more powerful meta-language is sufficient to define truth in the simpler language.

Now, an ordinary person may think that this solves the problem, but for a mathematician looking for the “one language to rule them all” this is not that consoling.

9. The halting problem

Alan Turing attempted to tackle the decision problem, which, in simple words, dealt with finding an algorithm that can answer whether a statement is true or not. In order to tackle this conceptually simple, but hard-to-solve problem, he rephrased it to the halting problem: is there a machine that can tell you whether a program will halt on a given problem?

Halting means that it will not loop forever. But how do you prove the infeasibility of a machine you know so little about? This is where paradoxes come handy.

Alan Turing began by assuming the existence of a machine which given an input program and a problem answers the question of whether it will halt or not. He then augmented this machine by looping its output back to itself if the answer was yes and halting if the answer was no.

So, will the augmented machine halt on the halting problem? Alan’s answer is: if yes then no, if no then yes. Sounds like bad news for logic.

10. The No Free Lunch Theorem

The passage to the 21st century signified a transfer from pure, almost philosophical mathematics, to applied areas, such as statistics and optimization.

If you consider yourself being fond of optimization, don’t you think this will make you a perfectionist? And wouldn’t a perfectionist want to find the optimal way to optimize things?

It seems that David Wolpert and William Macready sensed this need and came up with an answer, which, of course, was not encouraging at all (otherwise it would not be in our list). According to their No free lunch theorem for Optimization, published in 1997, “any two optimization algorithms are equivalent when their performance is averaged across all possible problems.”

Heart-breaking this may be, it does not mean optimization is futile. We’ll just never find a generally optimal way to do it.

These moments made the world of mathematics feel awkward, which is a light term for the feelings of despair and chaos that scientists tend to experience when the universe stops making sense. But shock is the way to move science forward.

Mathematical fields were created, we got the Turing Machine, fancy looking surfaces and, most importantly, the ability to re-examine our perceptions and adapt our tools accordingly.

These questioning moments helped us evolve intellectually.

Except for the incompleteness theorems. These were just devastating.

The history of the web and JavaScript is truly fascinating. ?

So I created this 19-minute video to help web developers understand it and learn from it.

In summary, you’ll learn the following:

• What JavaScript, the DOM, and CSS are, and how they came about.
• What ECMAScript, W3C, and TC39 are, and how they came about.
• That the evolution of these technologies didn’t happen in straight lines. There will be periods of chaos, periods of stagnation, periods of innovation, and so on.
• Contrary to the myth that “startups innovate and big companies don’t do much”, big companies do innovate a lot. But they also have strategic interests. And history shows that big companies actually run the show.
• Don’t wed yourself to a framework or a library.
• Standards are created to democratize innovations. Understanding standards, and participating in things like W3C and TC39 help everyone.

Further, you’ll learn that although there is a lot going on in the JavaScript world, things will be better in the coming future:

1. Expect “standards” to emerge
2. Expect future tools to abstract away a complexities (like create-react-app did)
3. Expect “simpler” and “smaller” frameworks to emerge. They will be much simpler than React, Vue, and current leading frameworks!

Note that this talk mainly focuses on the perspective of the creators of browser and JavaScript itself. It doesn’t talk about evolution of servers or mobile technologies.

Thank you for watching! ??

You can follow me on Twitter and tweet any questions you may have about this to me.

?? Thank you!

If this was useful, please click the clap ? button down below a few times to show your support! ⬇⬇⬇ ??

My Other Posts

ECMAScript 2015+

1. Check out these useful ECMAScript 2015 (ES6) tips and tricks
2. 5 JavaScript “Bad” Parts That Are Fixed In ES6
3. Is “Class” In ES6 The New “Bad” Part?

Terminal Improvements

1. How to Jazz Up Your Terminal — A Step By Step Guide With Pictures
2. Jazz Up Your “ZSH” Terminal In Seven Steps — A Visual Guide

WWW

1. A Fascinating And Messy History Of The Web And JavaScript

Virtual DOM

1. Inner Workings Of The Virtual DOM

React Performance

1. Two Quick Ways To Reduce React App’s Size In Production
2. Using Preact Instead Of React

Functional Programming

1. JavaScript Is Turing Complete — Explained
2. Functional Programming In JS — With Practical Examples (Part 1)
3. Functional Programming In JS — With Practical Examples (Part 2)
4. Why Redux Need Reducers To Be “Pure Functions”

WebPack

1. Webpack — The Confusing Parts
2. Webpack & Hot Module Replacement [HMR] (under-the-hood)
3. Webpack’s HMR And React-Hot-Loader — The Missing Manual

Draft.js

1. Why Draft.js And Why You Should Contribute
2. How Draft.js Represents Rich Text Data

React And Redux :

1. Step by Step Guide To Building React Redux Apps
2. A Guide For Building A React Redux CRUD App (3-page app)
3. Using Middlewares In React Redux Apps
4. Adding A Robust Form Validation To React Redux Apps
5. Securing React Redux Apps With JWT Tokens
6. Handling Transactional Emails In React Redux Apps
7. The Anatomy Of A React Redux App
8. Why Redux Need Reducers To Be “Pure Functions”
9. Two Quick Ways To Reduce React App’s Size In Production

If you have questions, please feel free to ask me on Twitter: https://twitter.com/rajaraodv

If this was useful, please click the clap ? button below a few times to show your support! ⬇⬇⬇ ??

I have a daughter who has a special blanket. The blanket is so special that its name is “Special” or “My Beloved.” Special has been part of the family for eight years. As you can imagine, it’s an important part of household happiness. As parents, we knew that Special would be difficult to replace, so we always kept an eye on it.

_Special in action with vintage [Hipstamatic](http://hipstamatic.com/" rel="noopener" target="blank" title=") effects

Special was an early artisanal purchase on Etsy, sans mass-manufacturing. The blanket was created from two different fabrics stitched together. In a few years, we discovered that the top fabric design (a vintage Japanese print) was discontinued and the entire blanket was no longer available.

_[Discontinued](https://www.etsy.com/listing/202281357/echino-nico-vespa-fabric-echino-scooter" rel="noopener" target="blank" title=") vintage print :(

Over time, Special became worse for wear. The top fabric peeled off. The body started fraying. The blanket fell apart into several pieces. As time progressed, the pieces were dropped and lost. Each missing piece resulted in a crisis.

After eight years, we only had a single sliver of Special left. Our fear was that the last scrap would be lost and the blanket gone forever. The family’s task was to remember when and where we last saw Special.

We decided we needed help to preserve our fragile memories. That’s where the Tile came into the mix. The Tile is a little flat piece of plastic, connected to an app, that you can clip onto anything. The components allow you to find any lost object within a 100-foot radius. Its design is straightforward — launch the app, tap the Tiled object, and if the object is in radius, it’s Tile will play a song. In case the Tile is out of radius, the app will show you the last location of the lost object.

After a while with the Tile, I noticed a change in our daughter’s behavior. She was no longer intensely concentrating on where she last saw her blanket. Instead of trying to remember where she last had it, she was fine with using the Tile to find it.

_Theuth via: [http://www.john-uebersax.com/plato/myths/phaedrus.htm](http://www.john-uebersax.com/plato/myths/phaedrus.htm" rel="noopener" target="blank" title=")

Plato’s The Phaedrus

This changed behavior reminded me of Plato’s The Phaedrus. In it, Socrates shares the story of the ancient Egyptian god Theuth, inventor of letters, and king Ammon’s response. Socrates quotes a discussion between Theuth and Ammon: “This discovery of yours will create forgetfulness in the learners’ souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves.”

According to Plato, Socrates’ fear was that we are substituting our memory with the written word. We are weakening an inherent ability with an artificial device. We are choosing to forget something as it can be recalled from outside ourselves. That seemed similar to the behavior that I observed. But the Tile is not responsible for this behavior. Instead, it’s within ourselves. It’s a mechanism that forms our mind, called the Zeigarnik effect.

The Zeigarnik effect

In psychology, the Zeigarnik effect states that people remember uncompleted or interrupted tasks better than completed tasks. It also affects us in reverse. If our mind realizes we no longer need to hold information, it allows the information to be held by an external device. Our mind does not preserve information that’s already retained. Instead, it saves its energy to capture new information and process it into newer knowledge. It’s up to us as individuals to put the excess energy to use.

A study by Betsy Sparrow found that people are less likely to remember information if they know they can access it later. Why remember the information when you can use Google to recall it later? More information about the Zeigarnik effect can be found in Scientific American.

Prometheus bearing fire

Prometheus and Fire

The story of Prometheus and fire is also a story of how technology affects us. The story goes that Prometheus felt sorry for humans as we had no natural abilities to protect ourselves. We were not born with augmentation such as claws or scales, but were instead naked and defenseless. So Prometheus stole fire from the Gods and gave it to humans. According to Socrates, “A gift of gods to men [i.e. the art of invention], as I believe, was tossed down from some divine source through the agency of a Prometheus together with a gleaming fire.” (Plato, Philebus 16b, trans. Fowler)

Fire gave us warmth. With fire, we sustained ourselves with cooking. Fire also gave us the ability to augment and protect ourselves with tool making. Tools merged with science to forge technology.

The root of the word technology also traces to Greek. The Greek term Techne, which means “art, craft,” combined with Logia, study or knowledge of things, to become Technologia, the study of art or craft.

Fire is a source of creativity and transformation that clears the old and brings in the new. Tools and technology represent an augmentation of fire that propels our ability to create change. Tools create one-to-one change while technology creates societal change at the same time.

As a designer

As a digital product designer, I work with technology to create tools. I enjoy creating tools to help people. As such, its not just technology that creates change — it’s us. Human nature drives why we create and design. Jared Spool defined design as “the rendering of intent.” He stated that “the designer imagines an outcome and puts forth activities to make that outcome real” in this article.

As designers, we are part of a long tradition of thinking and making. We have to consider what is the purpose of our work. As the Greeks said, we need to examine our work beyond our intent. We create change with our technology, and our technology changes us.

As a parent

I still find the Tile to be helpful. We still attach it to the blanket when we travel or break the usual routine. Also in my old age, I am ordering another couple of Tiles to keep track of my own things. I need a small Tile to fit on my AirPods container because I often misplace it. I wonder what Socrates would’ve said about that.

If you enjoyed this article, please give me some claps so more people see it. Thanks!

I recently read Barry M. Katz’s “Make it New” and am convinced that it’s a must-read for any digital product designer.

Make It New traces the role of design in Silicon Valley.

It’s the story of how a group of outcast designers in Silicon Valley transformed the design field. It’s how they advocated and advanced design from decorating hardware cases to strategic leadership. It’s the history of how these designers defined new design fields within Hewlett-Packard, Ampex, Apple, and a new breed of product design consultancies.

Silicon Valley designers became leaders of all new domains: interaction and (digital) product design. Fields ignored by traditional advertising and graphic design. As such, they were free to explore ergonomics of physical computers and interaction of virtual interfaces. Previous constraints and traditions did not apply. Instead, their creativity created the new field of interactive experiences by merging engineering with humanities.

Design in Silicon Valley was also defined by the freedom of designers to move between research institutes, corporations, and starting their own shops like frog, IDEO, and Lunar. This web of opportunities led to a fluid transfer of knowledge amongst the entire industry. New skills learned in one area were advanced in the next. Knowledge grew as designers jumped into new opportunities and collaborated. Disparate design experience intersected and created new interaction patterns and interfaces.

An important source of San Francisco Bay Area design innovation is West Coast Higher Education. The first wave of postwar designers attended the Art Center College of Design in Los Angeles; a school focused on industrial design, illustration, photography, and advertising. It trained many returning post-war veterans that became the first generation of Silicon Valley designers. In the South Bay, a short distance from each other Stanford and San Jose State University added into the mix theoretical and technical designers. In the Oakland hills and the Dogpatch of San Francisco, the California College of Art added a new group of designers trained in interaction and business.

Design in Silicon Valley is much richer than just Steve Jobs and Moggridge. It includes people such as Carl Clement, who in 1951 was the first designer at HP. He redefined HP products by introducing standardization across all products. The final interface of hardware products was born from his introduction brainstorming and user research into the product process. Techniques that we now consider standard but in 1951 were revolutionary.

Of course, military and government were key players in the growth of technological innovation in Silicon Valley. The federal government unintentionally helped as it sponsored the development of computing that in return required designers to make more humane. Make It New touches on the government’s role shaping the foundation of computing.

The history of design in Silicon Valley is multithreaded and deeper than told in the popular press. Make It New is a great overview of the evolution of design in the Bay Area. The book ends not in the past but in the present as it touches on the role of AirBnB, Facebook, and startups in creating the next generation of Bay Area design innovation.

Make It New: The History of Silicon Valley Design By Barry M. Katz. MIT Press 2015. 280 pages.

Make It New
_The role of design in the formation of the Silicon Valley ecosystem of innovation._mitpress.mit.edu