Data and types
How information is represented as bits, and why types give those bits meaning.
- Explain why every value is ultimately bits, and what a type adds
- Name the common type families and when to reach for each
- Read a type error as useful information rather than noise
Underneath everything, a computer stores only bits — ones and zeros. A type is the agreement that says how to interpret a particular pile of bits: as a number, a letter, a truth value, a list. Same bits, different meaning. Types are how we keep that meaning straight.
Bits become meaning by agreement
The bit pattern 01000001 could be the number 65, or the letter A, or part
of a colour. Nothing about the bits themselves decides which — the type
does. This is why "everything is just bits" is true but not the whole story: the
type is the lens that turns raw storage into something you can reason about.
The common type families
Across nearly every language you'll meet these:
- Numbers — integers (
42) and floating-point/decimals (3.14). Integers are exact; floats trade exactness for range, which causes the famous0.1 + 0.2 ≠ 0.3surprise. - Text — strings:
"hello". Sequences of characters. - Booleans —
true/false. The basis of all decisions. - Collections — lists/arrays (ordered), maps/dictionaries (key→value), sets (unique items).
- Nothing — a dedicated "no value here" type (
null,None,nil,undefined).
Static vs dynamic typing
Languages decide when to check types:
- Statically typed (TypeScript, Rust, Go): types are checked before the program runs. Mistakes are caught early, at the cost of writing them down.
- Dynamically typed (Python, JavaScript): types travel with values at runtime; a mismatch surfaces only when that line actually executes.
Neither is "better" — they trade earlier safety against quicker flexibility. Knowing which world you're in tells you when to expect a type error.
A type error is a gift
TypeError: can only concatenate str (not "int") to str looks hostile, but it's
the language refusing to guess what you meant by mixing a number and some
text. That refusal is protecting you from a silent, much harder bug later. Read
type errors as "you have two incompatible kinds of value meeting here" and fix
the mismatch — usually by converting one explicitly.
Beware "stringly typed" code — stuffing dates, numbers, or structured data into plain strings. You lose every check the type system would have given you, and the bugs move from compile time to production.
Where to go next
With values and their types in hand, we can start doing things with them: logic and control flow — making decisions and repeating work.