The Circle of Annoyance

A few months ago, I got a job. They pay me and everything! Specifically, they pay me to work on an internal tool for the customer engagement team. This tool is written in Java using the Play! Framework.

I might have more to say about Play in a future post. Then again, I might not. My feelings on it are pretty neutral. It’s an MVC framework. You got your models, you got your views, you got your controllers. It’s more verbose than Rails, being Java, but not hugely so. It’s rather like Django, but with batteries not included. The framework is actually implemented in Scala, and the template language is a weird Scala DSL that compiles to Scala functions that generate HTML. I’m not a huge fan of Scala. I’ve seen some incredibly nice libraries written in it, but you, and by you I mean I, have no chance of writing a library like that, because the implementation of that library is file after file of gobbledegook that looks like the horrific love child of the section of the Java language specification on generics and an academic paper on Hindley-Milner type theory. On the other hand, the arguments to Play templates are statically typed. This is nice, because templates are completely impossible to debug, and that goes double for these ones.

There was a time when Play was the only lean web framework for Java and all the other ones were eldritch monstrosities spawned in the moss-lined cesspits of unknown Kadath, but nowadays it’s a singularly unimpressive piece of work. What I’ve seen of Spring Boot really doesn’t look that bad, for instance. Play does seem more Java 8-ready than most of the other web frameworks, but given how watered down Java 8 turns out to be once you’ve spent a little time with it, I’m not sure how much I really care.

But that wasn’t the point of this little discussion. The tool I work on at my job, which I got, where they pay me, and in return I try not to force push my branch with three dumpy commits into the master branch on their GitHub repo, thereby destroying the entire app, was written by another developer who left the company before I joined. And his code drives me fucking crazy. I mean it. It drives me up the fricking wall. The formatting is a mess. The design is monolithic, impenetrable, and basically impossible to unit test. Some of the methods are 200 lines long. In one place, he checks if a string is empty or contains only whitespace using Apache Commons’s isNotBlank, while in the next he performs the exact same check using Spring’s hasText. (If Java had just included basic shit like that in its standard library, this wouldn’t be a problem.) Recently, I had to read the code that implements the tool’s Salesforce integration. While reading this code, I felt myself succumbing to the madness of the moss-lined cesspits of unknown Kadath. I started to jump at small noises, like the ringing of telephones or the questioning of dev-ops. When I came upon a coworker in the halls, I would low like a moose calf, or yap like an arctic fox, such was my shock at the sight of another being. I covered pages and pages with diagrams and flowcharts, trying to make sense of it all, finding clues to the purpose of a method in newspaper obituaries, seeing the organization of a class mirrored in a bowl of quinoa salad, muttering HTTP status codes under my breath.

So I rewrite the code, because it’s been made clear to me that this is now my code, and I can do whatever I want with it as long as the tool continues to work. (Well, the senior developers might protest if I decided to implement my own dialect of APL with an embedded MVC DSL on top of Play and rewrite the entire tool in that. But…but I can refactor all I want…so…so shut up! At least I have a job, where they pay me! They even let me write unit tests! So there!) And every few minutes, as I’m rewriting the code, I think about some future person, looking at this code. It might even be me, in the future. Or it might be some other junior developer who comes in to keep the tool running so our customer success team knows what our customers are up to. And I think about this future developer looking at this code, the very code I’m writing as I think this, and being driven fucking crazy by it.

I can’t even imagine what exactly this future developer will hate about the code I’m writing today. All I know is that he (or she–50/50 by 2020) will hate it. It will drive him/her/it/them fucking insane. He/she/it/they will be madly scribbling on the walls trying to understand this squamous code. Luckily, the walls are IdeaPaint, so they’ll erase. But the pain won’t.

And then, maybe, some day in the even further future, a further future developer will read the future developer’s code, and it will drive them fucking crazy. Even their genetically enhanced cyborg brain won’t be able to penetrate such code. It will be like that one episode of Star Trek: The Next Generation where Data came up with a plan to kill the entire Borg Collective by making them look at a really weird shape that would blow their minds, man.

It’s all part of a great circle of crappy code. Simple, crappy code becomes complex, crappy code becomes complicated crappy code becomes simple crappy code again, and at each step, a developer’s mind is lost. Someone has to break the circle of crappy code. They have to write good code. They have to rewrite the entire app in Yesod. Only then will the clouds part, and the darkness pass, and the compiler sing, and the tail calls be optimized, and the gods smile upon this little blue binary. Only then will the circle be broken.

Actually, it will probably still be crap.

Advertisements

Teachers, let your students use the standard libraries!

This is not a blog.

No, that wasn’t some kind of Magritte reference.

Because this is not a blog, this is a plea. I am pleading with you, professors, to end this madness of forbidding your beginning students from using the standard libraries in the programming languages you’re teaching them. And not just college professors, though they are most at fault here. This is a plea to anyone who teaches beginning programming, at any level and in any capacity, to LET! YOUR! STUDENTS! USE! THE! LIBRARIES!

If you want to get really crazy, you could even teach your students to use the libraries. I don’t expect that, but it’s something to consider.

Teaching beginning programmers at an extremely low level of abstraction, which is usually the reason for banning the standard libraries, never causes anything but pain. The students hate it. Not only is it painful, not only does it force them to accept what seem to them like bizarre and arbitrary restrictions on what code they can write, it’s also boring. They can’t do anything cool, like make a game or put up a website. All they can do is write dorky little interactive command line interest rate calculators and Fibonacci printers. And it makes things harder on you, too. You have to help students debug their ridiculously complicated programs that would be so much simpler if they could just use a list, but they can’t, because you won’t let them, because you learned to program in Pascal and doggone it, Pascal doesn’t have lists!

I understand that you want your students to learn how to use arrays, but frankly, knowing how to use arrays is just not an important skill anymore. Besides, teaching arrays by forcing students to use them in Java, C#, or even C++ is just lame. I firmly believe that the best way to teach a programming concept is to teach it in a language that takes that concept to the max. Java 8 supports a weaksauce sort of subset of functional programming, and Python supports a slightly stronger, but still pretty weaksauce, form of functional programming. But if you really want someone to learn functional programming, you don’t teach them Java 8 or Python. You teach them Haskell, or Clojure, or Erlang. Similarly, if you want them to learn arrays, teach them C, or assembly language. If you teach them C, they’ll learn not just arrays, but lots of other useful things about how real machines work. If you teach them Java, but force them to use arrays, they’ll learn that you suck.

Even more absurd than forbidding your students from using lists and maps is forbidding them from using built-in sorting. Don’t make your students write a freaking bubble sort just to sort the arrays that you made them use instead of lists or maps. Bubble sort is stupid, and your students aren’t going to get anything out of being forced to implement it after three months of programming experience. Instead, let them use built-in sorting. Later, when they take an algorithms course, they can learn a real sorting algorithm, like Quicksort. Then they can forget that as soon as the test is over and keep using built-in sorting.

There’s some room for forbidding, of course. If you’re teaching the students how to implement a linked list, you can forbid the standard library’s list. If you’re teaching functional programming using Common Lisp, you can forbid rplacd. (You should probably forbid rplacd just because it’s called rplacd.) If you’re teaching an assignment on self-hosting C compilers, you can forbid the following program:

#include "stdlib.h"
#include "strings.h"

int main(int argc, char** argv) {
    char command[50];
    strcpy(command, "gcc ");
    strcat(command, argv[1]);
    return system(command);
}

But if your students are writing a dorky interactive command line app, for goodness’s sake, let them use the libraries. Stem the tide of students coming to Stack Overflow with programs that look like this:

int main(void) {
    int var1;
    int var2;
    int var3;
    // . . .
    int var30;
    int var31;

    // Now calculate the monthly value
    int sum = 0;
    sum += var1;
    sum += var2;
    // . . .
    sum += var31;
    cout << sum << " is the sum." << endl;

And teach your students good habits, like using built-in sorting instead of writing their own crappy bubble sort.