Don't Be Afraid of Types

Types as Transformations and ETL

• Several comments echo the article’s view: most application code is effectively ETL—data comes in, is transformed, and goes out.
• Thinking in terms of “types and conversions between types” (including simple request/response structs) is reported to improve structure, naming, and unit testing.
• Examples include using Pydantic models or simple record-like classes with explicit from_X / to_Y mappings, ideally pure and side‑effect free.

Why Developers Avoid Defining New Types

• In Java/C++/old Python, the ceremony around classes (constructors, visibility, files, packages, tests) makes “just a new type” feel like “a mini app,” so people default to primitives and long parameter lists.
• Even in TypeScript, there’s a trend to lean on inferred types; when inference fails, error messages become unreadable.
• Some argue company culture, not language, turns classes into “architecture components” that feel expensive to introduce.
• Others point out newer constructs (records, data classes, algebraic data types, simple type X = Y) make small types cheap and encourage their use.

Naming vs Anonymous / Structural Data

• A recurring obstacle is naming: creating a tiny struct or DTO is resisted because “every little thing needs a name.”
• Counterpoint: structural or anonymous types (tuples, TypeScript object types, Clojure maps) let you express “anything with first_name and last_name” without inventing ObjectWithFirstNameAndLastName.
• There’s tension between flexibility of anonymous/duck-typed shapes and the readability/safety of explicit, named domain types or interfaces.

Benefits of Types: Grouping, Narrowing, Invariants

• Grouping related fields into a single type reduces verbosity and makes extension (adding a field) easier than threading many primitives.
• Type narrowing is highlighted as a major benefit: replacing many null | string fields with null | User communicates and enforces invariants like “either all fields are present or none.”
• Domain types (e.g., UserId, probability types, sorted-vector wrappers) let validation happen once at construction and prevent whole classes of misuse.
• Analogous advice appears for databases: don’t fear many tables if they model the domain cleanly.

Costs and Misuse of Types

• Critics warn that bundling unrelated parameters into a single struct can create “combo types” that accrete fields for multiple call sites, harming API clarity and compatibility.
• New types add cognitive load: consumers must learn what the symbol means and how it should be used.
• Overzealous OOP culture (insisting on rich behavior, encapsulation, DDD, factories, singletons) can make simple data types feel heavy and lead to “ravioli/lasagna code.”

Dynamic, Typeless, and One‑Type Styles

• Some enjoy “everything is X” paradigms (word, byte array, table, string, file) as liberating and claim explicit type systems aren’t necessary.
• Others respond that types still exist implicitly in the programmer’s head; the lack of static checking just defers errors and doesn’t scale to larger systems or teams.