"Code to Joy"

Ludwig von Beethoven “The thing that gets lost,” he says, “and which I think is important to know, is that programming is never easy. You’re never doing the same thing twice, because code is infinitely reproducible and if you’ve already solved a problem and you encounter it again, you just use your old solution. So by definition you’re kind of always on this frontier where you’re out of your depth. And one of the things you have to learn is to accept that feeling – of being constantly wrong.” - Quincy Larson, quoted by Andrew Smith in https://www.1843magazine.com/features/code-to-joy Information is where you find it, and if you go looking for articles that require a little thinking they have a way of finding you.  Case in point: I'm not a regular Economist reader (1843 is a cultural offshoot of the Economist), but this article by a journalist who decided to learn to code bubbled up on my news feed one day. I read it, and I'm glad I did.   Ode To Joy is also the fourth movement of Beethoven's Ninth (which is why he gets a cameo), and the Code to Joy title seems to me to reflect the way that dedicated and skilled professionals feel about their life's work.  It may play into the interfaces necessary for making a symphony work, but I didn't read that much into it. Anyway, this sentence really stood out to me "...you’re kind of always on this frontier where you’re out of your depth. And one of the things you have to learn is to accept that feeling – of being constantly wrong.”  It sounds kind of sporting, doesn't it?  It is, but that's why we love it.  There's always that little hit of adrenaline that kicks in because we don't absolutely know what's going to happen next. Let's pull back a few klicks and challenge a word we've gotten too comfortable with.  Mathematics is no more just arithmetic and geometry than "Life" is last night's leftovers and mowing the lawn.    Computer science, it may surprise you to hear, is applied mathematics.  I usually say "an applied mathematic" but that's just to emphasize the point, because the real experts like to fight over whether "applied" or "pure" mathematics is better.  I think it's kind of a dumb argument. https://xkcd.com/435/ Math is funny stuff for both the pure and applied mathematicians with lots of ties to music, language, philosophy, and logic.   In fact, a big chunk of a math degree (especially pure math) once someone finishes the calculus series is how to use that logic to prove things called theorems. Here's one: "if group A includes all the pasta types, and group B includes all marinara sauces, then every pasta meal has marinara sauce."  A Skyline chili just blows that away, and the disproof - the proving it false, is both tasty and trivial. The point being that some things are easier to prove than others, and most of them depend on some sort of assumptions and definitions we make along the way. Parts of CS (Computer Science) are a really peculiar fusion of the pure and the applied - the code must do something, so it is "Applied Math," but it is subject to theoretical constraints and proofs, so it elbows into "Pure Math" too.  Consequently neither type of mathematician totally trusts CS, at least until they need a job.  (My background is a mix of applied math and CS, so I catch shade from everybody.  :-D   ) You might have guessed that proving things about code is where we're headed, and you'd be right.  You can just whale on the code until it's bludgeoned into something like cooperation, but this is horrifying.  Yes, you get this wobbling object that trots itself partway across the field (yay! the robot works!!) but then it disgorges its bits and bytes in a public and appalling display of the perils of illogic (wow, what went wrong with the robot and can you fix it in 5 minutes?!).  That's no fun at all. If you'll indulge me the source, once upon a time a Roman named Paul wrote "all things are legal; not all things are profitable" and the blunt force method is ... unprofitable.   You see, after you put down the clubs, hammers, and open flame that method relies on, someone else is going to have to make a change to that dented and quivering carcass of logic, and they will either break it, or break it and soundly curse you and three generations of your heirs as "the reason we can't have nice things." There are better ways. I've been doing this for money off and on since Reagan was president, and in between waiting for Windows, waiting for compilers, waiting for ... you get the idea, I've had some time to contemplate and some time to read the evolving theory of this science.  I'll be darned if we don't agree - 1) the fastest, cheapest way to make code is to do it correctly. 2) it's called the correct way because it is the fastest, cheapest way to make code. 3) if you want it to stagger to a collapse right when you need it most, do it the blunt instrument way. I've posted earlier that the hard part of making software is not the little pieces of logic that make the individual things happen.  The hard part is figuring out which little bits you need, how to make them play nicely with the other little bits, how to write as little code as possible, and how to reuse as much of what you do write as you can. Another hard part is how to get to where you believe what you have might work.  There's a difference between actually believing it will work and saying "if anything's going to happen, it's gonna happen out there."  We're supposed to be training the students, after all. If you can sniff out a bug before you ever compile or download it, you've saved some time.  Do this enough, and you get some freed up practice sessions where you can work on other, more interesting problems. A good lint tool can help with both of these.  Here's a picture of some team code that's been linted:

Notice on the right side there aren't may little yellow lines.  Most of our code files have 20-50 or more lines of various colors - every one of which is a Lego on the floor of our code, just waiting for us to step on it in the middle of the night. Could be a piece of data that's defined in the wrong place, an improperly defined class, or a variable that is never read, only set because it's name is really close to the one we meant to use, could be one of a hundred different things.

So for the mentors, we really do have to resist the temptation to start slashing and burning our way through the jungle of this year's competition, we really do need to help the students start thinking about the design early and how they're going to communicate it among themselves, and just as importantly, how serious we're going to be about driving out those endless annoyances of "incorrectly scoped variable," "variable declared but not used," and "code never reached."

I'm hoping "Very Serious."

In the last post I discussed using Sonarlint - which I still like for a couple of reasons. I spent a day last holiday break going over 3.5 of our team code and actually learned quite a bit about Java conventions and was able to deduce why they exist.  Sure I questioned the wisdom sometimes while I was doing this, but when I finished I looked it over and it really was tighter, easier to read, with less wasteful code.  And if it looks like that to me, it's going to look a million times more like that when we shove it into the microprocessor to run "hot."

 To install it in Android Studio select the leftmost pulldown, then from File -> Settings -> Plugins -> "From Repositories" then scroll down to find SonarLint.  Here's a picture of my menu screens for this job:

Here's a link to my github of our team code set up for the 3.5 FIRST release.  We'll probably have to make some small changes to connect our team code to the FTC code for 3.7 or 3.8, but the team code wouldn't need to change much.  https://github.com/50N40W/KP35-Bravo

To close out in a full circle kind of way, here's another take on "Ode to Joy"