Programming is hard – Part 1

By Greg Turnquist

Greg L. Turnquist worked on the Spring team for over thirteen years and is a senior staff technical content engineer at Cockroach Labs. He was the lead for Spring Data JPA and Spring Web Services. He wrote Packt's best-selling title, Learning Spring Boot 2.0 2nd Edition, and its 3rd Edition follow-up along many others.

September 21, 2011

NOTE: You can read Part 2 and Part 3 of this blog series as well.

I have read enough articles debating whether or not scala is hard, and having recently watched a YouTube video clip of a kid presenting his Game Of Life app, I just have to weigh in.

Coding in scala isn’t hard. Watch the clip and think about everything that is happening here. I can hear a 11-year-old talking about looking up neighbors, calculating how many items are nearby, creating new and empty grids, two-dimensional sequences, so on and so forth. This kid is tackling what is really hard: writing computer programs using fundamental constructs found in any language.

How many of you reading this actually started learning programming when you were in college? I doubt any of you did. Instead, you were probably some geek kid when you first dabbled. What did you use? BASIC, Pascal, Logo, Prolog, Smalltalk, something else? Did you know all the constructs at the time? Did you understand things like object oriented programming, design analysis, or refactoring? I’ll venture that you started out learning things like for loops, setting variables, and fiddling with making some sort of output, whether it was text on the screen or pushing some sprite around on a screen. (I miss commanding a turtle to move around with the pen down in Logo on an Apple IIe).

And this is where the rubber hits the road: programming is fundamentally about learning how to make that computer do what we want using a handful of concepts. The basics of programming don’t involve complex analysis nor designing fancy structures. When we start out building programs, it’s kind of like building a dog house. We learn just enough to nail together a few boards and see some quick results. We are really happy when Spot had a nice little home that we nailed together and painted, and can see it everyday in our backyard.

The more complex stuff like object oriented analysis, technical debt, code coverage, and all that other stuff are more elaborate techniques we pick up later when we realize that we can’t use our dog-house building techniques to construct a skyscraper. But whether we are building a dog house or a giant tower, we are still manipulating some simple elements to construct a wonderful structure.

Let me go back to my college days. I once worked at the Agricultural Research Service at Auburn University, and developed a real-time control system used to test tractor tires. I built a program that commands the hydraulics on how much pressure to put on the tire, and whether or not my program decided to stop was based on the sensor feedback I got. Basically, I got a sensor reading, calculated how far it was off from my target load, and sent a followup signal to increase pressure at a certain rate.

This is where I really learned an amazing lesson. The system had so many factors that contributed to what was the right amount of force to apply. For example, if you are very close to the target load to place on the tire, you only want to increase the load by a small amount, but if you are far away, you want to increase the rate that force was applied. The system had delays. The time span to read a sensor and calculate a delta took milliseconds, but in that span of time, the apparatus kept moving, so there was always a certain amount of error in making this calculation. But there was absolutely no value in trying to calculate all these factors or analyze every aspect of the apparatus. Instead, I had to run trial after trial, seeking out two numbers: the immediate correction factor and summing correction factor.

You see, the formular for a real time control system involves two key factors: the first is making corrections based on the current delta between where you are and where you want to be. You find the difference, multiply it by some constant, and then send the actuator signal accordingly. 10 milliseconds later, you calculate the difference again, multiply it by the same constant, and send an updated actuator signal. The bigger the constant, the faster the system moves…and the bigger it will overshoot the target. The smaller the constant, the slower it will reach the target…and the smoother the transition will be.

But all control systems have a resolution that results in lurching back and forth over the target. That is where you have to also sum up the deltas and multiply it by the second constant, which is usually much smaller than the first one. This compensates for when the system starts drifting from either side of the target. It may be a small fraction, but after a few rounds, this drift becomes big enough that a course correction is needed.

In case you aren’t catching this: no amount of analysis will tell you what these two constants need to be to get the most efficient, smooth approach to target. In fact, if you try to analyze instead of testing out and using it, you will waste a lot of time for nothing. Instead, it requires empirical test runs until it works right.

Software is no different. No amount of analysis of language constructs, assessments of built in libraries, nor deductions about complexities can substitute for using the language to build something and seeing how it performs. When I watch an 11-year-old kid take command of scala and build the Game of Life, that is a true empirical anecdote that tells me that scala isn’t too difficult.


Submit a Comment

Your email address will not be published. Required fields are marked *