The Art of Code

Log In Register
Go back to Regarding Data
Return to Level B3 Outline

Regarding Languages

Suppose you worked in an office and you noticed a package arrived for a coworker. The package was left at the reception desk. You want to inform your co-worker. If you were to say this in English, you would need to know whether the courier was male or female to formulate the following sentence in a grammatically correct way:

"The courier was just here. She left a package for you at the front desk."

The gender of the courier is irrelevant to the goal of the sentence so it should not be surprising that in some languages, this detail is omitted entirely. For example, if you were to say this same phrase in Japanese, you would not need to know the gender of the courier. But you would need to change the grammar depending on whether your coworker was older or younger than you or if it was your boss or subordinate.

Ultimately languages are supposed to solve problems. But in order to solve those problems, you need to sometimes figure out other things first as a grammatical necessity of the language itself. If a language is quite flexible and concise, it can leave unintended details to chance or the imagination. If a language is rigid and requires lots of details, it can be a frustrating chore to state simple thoughts, but at the same time it leaves very little room for incorrect interpretations. Even details you want to avoid.

Depending on the language used, your coworker may be left wondering about one of the following questions:...but probably not. Because these were not core details to the message. But nevertheless, the language we choose to use is a trade-off that will require us to include different types and amounts of information.

Programming languages are no different.

The commonality of programming languages

For simple coding problems, the overall structure of the code you write is mostly the same regardless of language. However, like the gendered pronouns of English or the social status verb conjugations of Japanese, once you have a general idea of what it is you want to say, you then have to apply the quirks of the language to create something that is grammatically correct.

The underlying structure of most programming languages are nearly identical. There are of course a few outliers and counter examples, but overwhelmingly programming languages look very similar to each other.

Like a package sitting at the front desk, let's consider another simple idea. But this time, it's an idea that can be expressed in code: counting backwards from 10.

The following code counts down from 10, displaying each number on the screen before shutting down. I've written this same program in C, Java, and Python. You don't have to understand what's going on here yet. You don't have to read each snippet for more than a few seconds. Just glance at each code snippet and compare them to each other to see for yourself that the overall gist is the same.

C

#include <stdio.h>

int main() {
    int number = 10;
    while (number > 0) {
        printf("%d\n", number);
        number = number - 1;
    }
}

Java

public static void main(String[] args) {
    int number = 10;
    while (number > 0) {
        System.out.println(number);
        number = number - 1;
    }
}

Python

def main():
    number = 10
    while number > 0:
        print(number)
        number = number - 1

if __name__ == '__main__':
    main()
It might surprise you to learn that C is considered an outlier and extremely different from the others despite being verbatim identical to Java in several lines. Python is considered to be one of the most concise languages. Java has a reputation of being notoriously verbose. And despite all that, the core message they convey looks mostly similar.

There is still a lot going on here and considerations that go into each line. However these considerations are specific to the language. Because the code itself is roughly identical, it can be surmised that the overall problem solving process to write this code was the same regardless of the language.

First Languages

A native English speaker learning Japanese will make many mistakes while conjugating verbs to their appropriate social status. A native Japanese speaker learning English will make many mistakes while applying pronouns. Neither of these foreign language learners natively think in terms that efficiently convey subtleties that are grammatically required in the other language until they've practiced to fluency.

In other words, the spoken language you learn first will most likely make a permanent influence in the way you formulate thoughts in the same way that the programming language you learn first will most likely make a permanent influence in the way you think as a programmer.

This leads into a common debate about learning programming: which language should one learn first?

The answer to this question usually lands on 4 languages.

Feet first
"Don't scare them off too quickly"
Head first
"Rip off the band-aid sooner than later. Filter the students that won't get it."
Long Timeline
(Habits focused)
Python Lisp
Medium/Short Timeline
(Results focused)
JavaScript C
These 4 languages represent the four philosophical corners of this debate.

Other languages (usually Java or Ruby) also come up and are usually proposed from the perspective of a middle ground or the student is extremely young and a visually-oriented language is desired (usually Scratch).
The one thing these 4 languages have in common is that they are industry-standard languages that are not immune to the effects of common use. These languages serve specific purposes and roles outside of their educational merit as a first-language. As the language evolves to be more efficient in day-to-day use, it may become less useful as a first language as it may obscure details that help you visualize how things work, details that a professional understands well and treats as grammatical minutia.

And since you're probably wondering: Lisp is an extreme outlier. If I showed the code above it would look like an alien language compared to the others.
As you learn a first language, it's sometimes hard to tell whether you're learning coding in general, problem solving, or if you're just learning trivia and conventions about the one language itself. If you plan on a career change, how easy would it be to transfer that knowledge from one language without negatively influencing your thought process or carrying over unrelated bad habits from the original language to the new language? This is a legitimate concern.

So which language will this guide use?

This guide uses a custom programming language that has been specifically optimized as a solution to the first-language problem. This language is called Common Lang and has two sub-variants: Dynamic Common Lang and Typed Common Lang.

From the count-down-from-10 examples above, you can see that most programming languages solve basic problems in the same way but contain differing nuances and a few conventions that are specific to that language. Learning how to solve coding problems is one challenge. Learning the quirks of your first language and separating it out as trivia knowledge vs core knowledge is another challenge. Common Lang reduces this problem as much as possible by creating a language that does not aim to be fast, industry-efficient, tolerate small mistakes caused by misunderstandings, or provide elegant shorthand. It aims to resemble most languages but with a focus on consistency and transparency of what the computer is actually trying to do.

In effect, by using Common Lang, you are learning most languages at the same time but in a distraction-free environment. After Common Lang, this tutorial will switch to other languages one by one, but by then, all those languages will already feel very familiar and the quirks of those languages can be embraced as elegant shortcuts for things you have learned well, or as pitfalls that you have the wisdom to dismiss as such. In a highly compressed short-term timeline, this might not be the best path. But as earlier-stated, this guide assumes a goal of long-term mastery and you will likely understand other languages more deeply than those that learned those languages natively.