---
title: 'Choosing a Language'
source: 'https://academia.sh/en/courses/programming-fundamentals/choosing-a-language'
course: 'Programming Fundamentals'
language: en
updated: '2026-08-17T18:08:25+00:00'
license: 'CC BY-SA 4.0'
---

# Choosing a Language

The design axes that separate languages, criteria for choosing a first language, and knowledge that transfers.

This course built its concepts without tying them to a particular language; the
examples were written in a single language, but nothing explained was specific to it.
The question that closes the course is this: what separates languages from one another,
and which one should a learner start with?

The question has no answer of the form "which language is best." Languages are designs
that have chosen different trade-offs; what they gain on one axis, they pay for on
another.

## Why Languages Diverge

Every language is designed to make a particular set of problems easier, and that choice
makes something else harder. A language that offers control close to the hardware
leaves memory management to the programmer; a language that prioritizes safety
restricts that same control. A language that offers fast writing defers part of its
errors to run time.

For this reason, the question to ask when comparing languages is not "which is better"
but **"which trade-off has it chosen."**

## Distinguishing Axes

The distinctions touched on throughout the course are the axes that position languages:

| Axis | Ends | Where it appeared in the course |
|---|---|---|
| Type-checking time | Static ↔ dynamic | Basic data types |
| Type strictness | Closed to implicit conversion ↔ open | Type conversion |
| Memory management | Manual ↔ automatic collection | Memory layout (previous course) |
| Execution model | Compilation ↔ interpretation ↔ virtual machine | Compilation chain (previous course) |
| Mutability | Immutable by default ↔ mutable by default | Functional approach |
| Paradigm weight | Object-centered ↔ function-centered ↔ multi-paradigm | This topic |
| Concurrency model | Threads ↔ event loop ↔ message passing | Operating system concepts |

Learning a language means learning its position on these axes. Syntax is picked up in a
few days; what is actually being learned is which errors the language prevents and
which ones it leaves to the programmer.

An eighth axis is not technical but is decisive: the **ecosystem**. A language's
libraries, tools, and accumulated community knowledge set the boundary of what problems
can be solved with it. Even good language design does not help if no library exists for
the target domain — the work then begins before the language choice does.

## Choosing a First Language

When starting to learn, the choice is made by looking at the **learning experience**
rather than the power of the language. Four criteria are useful.

**Feedback speed.** Seeing the result of written code in a short time speeds up
learning. Long compilation and setup steps are extra overhead for a beginner.

**Quality of error messages.** A good message states what the problem is, where it is,
and what was expected. At the beginner level, this teaches more than a tutorial does.

**Visibility of concepts.** Some languages show this course's concepts openly: type
declarations, scope rules, memory behavior. Others hide them; this brings convenience
but delays learning the concepts.

**Applicability.** Being able to produce something useful with the language learned in
a short time sustains continuity.

These criteria do not point to a single language, and they should not. What matters is
staying with the chosen language long enough for the concepts to settle; switching
languages often results in relearning syntax each time without ever reaching the
concepts.

## What Transfers and What Does Not

How much knowledge carries over when moving to a new language depends on what was
learned.

**What transfers:** the whole of this course. Variables and binding, the concept of
type, control flow, the loop invariant, the function contract, scope rules, recursion,
the distinguishing ideas of the paradigms. These belong to programming, not to a
language.

**What does not transfer:** syntax details, standard library names, tool-chain
commands, language-specific idioms. These are relearned in every language and take
little time to relearn.

The ratio shifts with experience: in a first language, almost everything looks new; by
a third language, what remains to be learned is only the position on the axes and the
syntax. For this reason, time spent on a first language is an investment that carries
over to every language that follows.

A useful criterion when choosing a second language is that it **differs clearly from
the first on some axis**. Learning a statically typed language after a dynamically
typed one shows the concept of type from both sides; a manually managed language after
an automatically managed one makes the memory model visible.

## Problem Domain Narrows the Choice

Choosing a language for a project is a different question, and it generally leaves less
freedom. The deciding factors are the languages the target platform supports, the
libraries the domain requires, the team's existing knowledge, and maintainability.

The last factor usually weighs the most. Code is read and maintained far longer than it
takes to write; a language the team can read is a better choice than a technically
superior language no one on the team knows.

## Languages Change

A language is not a tool fixed at the moment it is chosen; it evolves across versions.
New constructs are added, mistaken decisions are corrected, some features are dropped.

This evolution produces one more axis that separates languages: **backward-compatibility
policy.** Some languages treat keeping old code running as the top priority and live
with their mistaken decisions as a result. Others accept breaking changes for the sake
of a clean design and pass the migration cost on to large codebases.

The practical consequence is that part of what is learned depends on the version.
Concepts are permanent; which version a given construct is available in is not. For
this reason, sources and documentation state explicitly which version they describe,
and code states explicitly which version it targets.

The same principle applies to dependencies: libraries are versioned too, and
compatibility rules work the same way. Version management is the subject of the
**Software Development Practice** curriculum.

## Wrapping Up This Course

The course started from the concept of a program and arrived at three organizing
approaches. In order: a program is an input–process–output transformation; values are
bound to names, and their types state which operations are defined on them; flow is
directed by conditions and loops, and every loop has a termination reason and an
invariant; functions name work and bind it to a contract, isolate scope, and make
recursion possible; paradigms determine which units these pieces are gathered into.

The same problem — summarizing a series of measurements — was solved four times over
the course: by hand with a loop, broken into procedures, through an object, and with
pure functions. All four worked correctly. The difference between them is not speed but
**how they respond to change** — and that is the criterion that becomes decisive as a
program grows.

## Summary

- Languages are designs that have chosen different trade-offs; comparison is done with
  the question "which trade-off has it chosen," not "which is better."
- Type-checking time, type strictness, memory management, execution model, mutability,
  paradigm weight, and concurrency model are the main distinguishing axes; the
  ecosystem is a decisive factor that is not technical.
- Feedback speed, quality of error messages, visibility of concepts, and applicability
  are the criteria for a first language choice.
- Concepts transfer between languages; syntax, library names, and tool commands do not.
- A second language makes an axis visible when it differs clearly from the first on
  that axis.
- Platform, libraries, team knowledge, and maintainability are decisive when choosing a
  language for a project.

## Next Step

Throughout this course, data was always kept in ready-made collections: a list was
given, and it was traversed. How is a collection actually stored, why is searching fast
in some structures and slow in others, and which structure suits which operation? The
next course — **Data Structures** — takes up these questions and brings together the
memory model from the previous course with the abstraction tools from this one.