AmouAI Hub/Courses/Programming Fundamentals/Day 23
Comparative Case Study + Capstone Kickoff
One non-trivial application, built twice. Where each language is pleasant, where each fights you, and when you would reach for which.
By the end of today you can
- Compare two implementations of one spec on evidence rather than taste
- Say where static typing paid for itself and where it cost you
- Estimate how each version would behave at ten times the size
- Choose a language for a stated problem, and defend it
- Scope a capstone you can actually finish
- Write a design document: spec, model, structure, risks
- Identify the riskiest part of your build and schedule it first
▶Today's videos
Watch each video, then work the matching sections below. Watching alone will not do it.
mypy · choosing a language for a stated problem, and defending it.1The same spec, twice
A library system, built in both languages. Same behaviour, same tests.
| Measure | Python | Java | Reading |
|---|---|---|---|
| Lines of code | ~320 | ~610 | Java's ceremony is real and roughly 2× |
| Files | 6 | 11 | One public class per file forces the split |
| Time to first run | minutes | longer | Compilation, and more to declare |
| Bugs caught before running | 0 | 14 | Typos, wrong types, missing overrides |
| Bugs found by tests | 9 | 3 | Java's compiler had already taken most of them |
| Bugs found after "done" | 4 | 1 | The expensive ones |
| Time to add a new item type | ~10 min | ~18 min | More to write, less to check |
| Time to rename a core method | ~25 min | ~2 min | Rename refactoring is exact when types are known |
Java cost more to write and far less to change. That is the trade in one line — and it explains why the answer depends on the project. Code that ships once and is never touched has different economics from code twelve people will edit for five years.
2Typing trade-offs
An honest ledger.
| Static typing wins when | Dynamic typing wins when |
|---|---|
| The codebase outlives its authors | The program is small and short-lived |
| Many people edit the same code | One or two people own it |
| Refactoring must be safe | Requirements change faster than the code |
| The API has external consumers | You are exploring the problem |
| Failures are expensive | Iteration speed is the priority |
Python has types — it checks them at runtime rather than compile time. And type hints plus mypy give you much of Java's checking without the ceremony:
def check_out(self, item_id: str, member: Member) -> date:
This is now standard practice on any Python codebase of size, and it moves Python meaningfully along the spectrum. The choice is not binary.
You now know what a class is, separately from Python's way of spelling it. You have felt why interfaces exist, because Java would not let you skip them. And you have seen the same idea — a name pointing at an object — in two type systems. That is understanding rather than familiarity, and it is not reachable in one language.
3Capstone kickoff
Choose it today. Design it today. Build it tomorrow.
Your capstone must be a working application in either language, with tests, documentation, and a defensible design.
Scope, honestly
Every unfinished capstone this course has seen was too big on day one. Pick something you could finish in half the time available, then use the other half for tests, edge cases and polish. A small thing finished beats an ambitious thing at 70%, and it is not close.
| Good scope | Too big |
|---|---|
| Expense tracker with categories and a monthly report | A personal finance platform |
| Command-line quiz app with saved scores | A learning-management system |
| Recipe manager with search and shopping lists | A social recipe network |
| Text-adventure engine with 6-8 rooms | An MMO |
| Library system extending Mini-Project 3 | A library system with a web front end |
The design document
- One paragraph. What it does and who for. If you cannot, the idea is not clear yet.
- User stories. Five to eight, in the form as a X, I want Y, so that Z.
- Data model. Your classes, their fields, and how they relate. Draw it.
- Module structure. Which file holds what, and what depends on what.
- Test plan. What you will test and which edges you expect to break.
- Risks. The parts you are least sure about — and schedule those first.
- Out of scope. Written down, so you can say no to yourself tomorrow.
Whatever you are least sure about — the file format, the persistence, the one algorithm you have not written before — build that first, in a throwaway script, before anything else. If it turns out to be harder than you thought, you find out on day one when you can still change the plan, rather than on day three when you cannot.
Section 7 matters more than it looks. "Out of scope: no web interface, no multi-user, no undo" is a sentence you write today so that tomorrow-you cannot quietly add them at 11pm.
>_Python playground
A real Python interpreter running inside your browser. Nothing is installed, nothing is uploaded, nothing can break.
input(), comma separated →
✓Exercise set
Checked automatically the moment you submit. Work top to bottom — each one assumes the last. Your answers are saved in this browser.
Day 24 — Capstone Build Lab
Guided build sessions, with a reference project built alongside.