Talking to machines requires learning to speak their language.

Consider aircraft and their pilots. The first planes were directly controlled by human intervention, information acquisition was through human sensory input and feedback, servo power was provided by human muscle. When you flew a cloth and wood biplane by the seat of your pants you used eyes, ears, sense of balance and spatial orientation and you pushed on the stick, throttle and pedals. Commands were transferred to control surfaces by rods and cables.You could FEEL when your ship was about to stall, or when the engine was running too rich or too lean.

Then we added hydraulic assists and servo motors to transfer our motion and strength to the machine. Instrumentation replaced flying by the seat of your pants, even the stall announced itself ahead of time with a buzzer. We were trained to ignore our senses and trust our instruments.

In today's fly-by-wire aircraft you don't fly at all, you tell a computer what you want the plane to do and it tells the aircraft what it needs to do to itself to execute that maneuver. Sure, you still have a stick and rudder, but they are only a user interface designed to be familiar to a pilot trained on an analog aircraft. You could just as easily fly using a mouse and keyboard.

Kids are good at learning languages, and they are quick to take advantage of the new capabilities of digital systems. When I learned to program in '64 most of my undergraduate lab work involved coding up algebraic equations for older PhDs who didn't know how, or who had taken the courses but still weren't comfortable doing numerical analysis with Fortran. Even those who knew how didn't feel comfortable with it; it seemed alien and cumbersome. But they needed the speed and the ability to process large datasets. Calculating a model of a stellar interior used to be a year long project for an astrophysicist, people used them as graduate theses. Now an undergraduate assistant, given the equations, could code it up in a few days, and the program could execute in a few minutes (even if the computer center had a 24 hour turnaround time!) And once the program was written and debugged and tested, you could change the parameters and run it several times a day to see how the results would vary.

Yeah, I used to be pretty arrogant about the old-timers too, how they had to come to me now just to publish bread and butter papers. But as I grew older I soon learned to sing the blues myself. I quickly fell into the tech trap, the more capable the technology became, the larger a proportion of our effort went into managing, maintaining and applying it. You spent less time on the job and more and more time debugging your tools, and more dependent on them even on doing the most routine tasks. You see, you now no longer get handed the equations to solve a physical system, now you have to worry about user interfaces, file structures, down line processing. As a mapmaker later in life I spent very little time using GIS to draw maps, I spent most of my time learning new software, new file formats, interfacing with other systems--in other words, overhead.

And the new kids coming out of school seemed to understand all that stuff so well, even if they couldn't tell the diff between lat and lon, or know what a map scale was and how to calculate it. Now I was the old-timer.

And you can count on one day have it happening to you, too.