A small price calculation
This episode turns a few named values into a useful calculation. We will price three notebooks in integer cents, print the result, and decide whether the total reaches a simple threshold. Working in cents keeps the arithmetic exact for this example. It is not a complete financial model. The point is to see how types, immutable bindings, mutable variables, and expressions work together in a program that is small enough to check by hand.

Start with the entry method
We keep the same Main class and static main method from the previous episode. This time, the body contains a sequence of declarations before printing results. You do not need another project architecture to start calculating things. The types are written explicitly so we can discuss them. In later code, type inference can reduce repetition where the intended type is already clear from the value and surrounding context.

Const names a fixed binding
The item name is a string, and unit price is an Int sixty four value. Both use const. That tells the compiler we will not assign a new value to those bindings later. The string is quoted; the integer is not. The name explains the role of each value, while the type explains what operations make sense. Here, twelve fifty means one thousand two hundred and fifty cents, rather than a text label containing those digits.

Var allows a later assignment
Quantity uses var because the example changes it. We begin with two notebooks, then assign quantity plus one back to quantity. The right hand expression is evaluated using the current value. The assignment stores the resulting value for later statements. After that line, quantity is three. This is a change of value, not a change of type: quantity remains an Int sixty four variable throughout the method.

Multiply named values
The total is unit price multiplied by quantity. Both operands are integers, so this expression stays in integer arithmetic. With a unit price of twelve fifty cents and a quantity of three, the result is thirty seven fifty cents. We bind that result with const because this example does not update the total again. The expression makes the business rule readable without hiding the underlying arithmetic from us.

A comparison produces a Boolean
Qualifies is a Bool value. Its initializer compares total with three thousand cents using greater than or equal. Unlike multiplication, this comparison does not produce another price. It answers a yes or no question. With our values, the answer is true. A Boolean is useful in conditions, which we will explore next time. For now, printing it gives us a direct way to see the result of the comparison.

Check the actual output
Build the example and run the resulting executable. It prints the item, the integer total, and the Boolean result on separate lines. We can verify every line without trusting the program's own explanation: the item is Notebook, the arithmetic gives thirty seven fifty, and that is at least three thousand. This habit of checking a small expected result independently becomes even more valuable when the examples later involve databases and network protocols.

Text is not an integer
Now place quotation marks around the unit price, while leaving its declared type as Int sixty four. Even though the text contains digits, its type is String. Tinox check rejects the declaration and reports the mismatch. It does not silently pretend that this is the same program. When input arrives as text in a real application, a deliberate conversion and its error behavior belong in the design. We will not rely on an accidental conversion here.

Const also catches unintended changes
For a second experiment, change the quantity declaration from var to const but leave the later assignment in place. The compiler rejects the reassignment to an immutable binding. That diagnostic is useful when a value was supposed to stay fixed. To repair this example, use var for quantity because changing it is intentional. Alternatively, a different design could compute a new named value instead. The right choice follows the meaning of the program.

Read expressions from their purpose
Arithmetic expressions calculate values. Comparisons ask questions about values. Assignments update mutable bindings. These are related operations, but they have different roles. Use parentheses when they make a larger expression easier to understand, and prefer meaningful intermediate names over a single dense line. In this example, unit price, quantity, total, and qualifies let us follow the reasoning in the same order as the statements execute.

Be precise about what is immutable
Our const bindings in this example hold simple values. We have demonstrated that those bindings cannot be reassigned. Do not turn that observation into a claim that every object reachable through a const binding becomes deeply immutable. Object mutation and shared state deserve their own explanation later in the course. For now, use const when you do not intend to replace a binding, and use var when a later assignment is part of the algorithm.

Exercise: change the outcome
Change the initial quantity to one. Remember that the next line still adds one, so the final quantity becomes two. Predict the total and the Boolean before running the program. You should expect twenty five hundred cents and false. Then try a different threshold and predict again. After the exercise, restore the supplied end state. In the next episode, we will use a Boolean to decide which tasks a loop counts.
