If you wrote "Input" you are on the right track, but there's more. The program still needs to know which button was pressed. We'll come back to that, but even more important is to let the user know what to type in. The $2 calculator you can buy at a Dollar store, the buttons are clearly labelled with the various calculator functions, or else digits of a number. The more expensive calculators have a zillion functions, and you have to read the user manual to know what they all do, or if you even want to use them.
Later on (in Java) we can do a calculator with the familiar interface, but for now all the user knows is that they have this "aircraft carrier" keyboard with 50+ keys on it, none of them the usual times or divide keys of the traditional 4-function calculator. The only way they can know what your program needs to see is for you to tell them. Rather than have them hunt all over the keyboard for special symbols to press, you might offer them to type in the first letter of whatever function they want: (A)dd, (S)ubtract, (M)ulitply, (D)ivide, (E)qual, and (C)lear.
We're not done yet. If you go back and look at the interaction you wrote up (or my version a couple pages back) you will see that this interaction alternates between the user entering a number and the user entering a function key -- except (not shown) after (E)qual the user typically pushes another function key. The best software just waits for the user to do something, then figures out what to do with it, but that's very complicated. So for now we'll do it the unix* way, and insist that the user conform to our program's agenda instead of the other way around. Be sure to tell the user what you expect them to do each time before you wait for them to type something in.
Why don't you replace your second line in the edit panel with something that better describes how the computer should handle the interaction. You might keep in mind how each line of your description fits one of the Five Concepts in the table below, but even if you don't always succeed, do your best, and then turn the page.
Five Basic Concepts Sequence Iteration Conditional Variables Input/Output
<<Previous | ToC | Next >>
[2021 April 30]
Unix The original Unix operating system was designed at (then) Bell Labs for their scientists to use. Scientists are mostly overgrown students, so it was designed to be very easy to program and (as a result) is very hard to use for doing real work. I call it "the conservation of complexity," somebody (either the user or the programmer) must do the hard work of making the computer do what we need it to do, and There Ain't No Such Thing As A Free Lunch (TANSTAAFL). Unix is still today easy to program and hard to use.
The 1984 MacOS was the other way around, and was so successful that everybody
else is now trying to be a Mac clone, but underneath the hood they are all
either unix or a unix wannabe, because the programmers who write the operating
systems are lazy, they want easy-to-program and don't give a rip about
easy-to-use. Today, while you are getting started, easy to program is good.
After you get good at it, you should transition towards writing software that
is easy on the users, because if they like it they will come back for more,
which translates into more income for you. The real reason is that it makes
the world a better place, and the USA is the richest country in the whole
world and in all time because people here do that.
TANSTAAFL
