Choosing the Language, Receipts Attached

Choosing a language for a real project is this unit run in reverse — criteria, typing, paradigms, concurrency, and implementation strategy each narrowing the field, with every elimination traceable to a stated property.

A team is building a records system for a clinic network: long-lived, maintained by many hands, correctness above all. Start with the criteria (0353): readability and reliability outrank writability for code that decades of strangers will read — simplicity and clean syntax design move up the scorecard. Typing next (0364): strong typing converts a class of silent mistakes into loud compile-time refusals, and after video 0371's dropped bytes, the team wants refusals — coercion rules get read before any signature is accepted (0365). Paradigm (0373–0376): patient records are natural objects — encapsulation hides each record's internals behind a promise, inheritance builds specialized record kinds from one ancestor, polymorphism lets one "display" behave per kind — so a language high on the object-orientation spectrum earns its place. Concurrency (0377): many clinics write at once, so the thread abstraction and the discipline of critical sections (0378) are requirements, not features. Implementation last (0381–0383): clinics run mixed hardware, which makes bytecode on a virtual machine — write once, run wherever the machine lives — worth the runtime layer, with just-in-time compilation (0384) clawing back the speed. Notice what never appeared: fashion, familiarity, or a favorite. The specimen case from videos 0354 through 0357 taught the same lesson historically — Fortran fit science, COBOL fit business — because fit, argued from properties, was always the method.