What does a computer program look like?
Let’s face it: lines of code ain’t so easy on the eyes. No matter how good they are, you have to stare at them to figure out what they do.
But what if we could see a program in terms of how its parts related to one another? How would you draw a picture of a program?
The typical “code” look becomes downright frustrating when you’re trying to debug. Your eyeballs pore over the program line by line while you keep a running line of notes in your head (or, if you’re really having a doozy of a day, on a notepad).
And so it’s not surprising that the folks who stick with programming tend to organize their thoughts according to sequence (associated with the left brain) as opposed to those who organize their thoughts according to their relationships with other thoughts (associated with the right brain).
This doesn’t happen because the latter type of person can’t be a good programmer. It just happens because:
1. That’s how programs are laid out.
2. That’s how most programmers, and by extension most programming teachers, think. And a person who thinks in one way can hardly even picture the other way, let alone explain something that way. Try to describe the difference between red and green to a colorblind person, and you’ll understand what I mean.
But what if we could draw a picture of a program?
I gave this a try. The result: a method-mapping program for Ruby (Java is in the oven!) Here is what happens when that program draws a picture of itself:
So initialize calls get_filename. Then it calls open_file, which calls read_file. Then initialize calls get_out_the_words_to_use_in_the_flowchart, which calls Identify_all_the_methods, which calls draw_the_method_in_diagram. Then initialize calls identify_all_the_methods, which calls set_current method. Then identify_all_the_methods calls are_we_inside_the_method?, which calls check_for_methods_inside_methods, which calls, finally, draw_connections.
Is it perfect? Clearly not. But believe me, it’s a fast way to figure out whether your methods are pointing to the right places. And, when combined with thoughtful method names, it’s a step in the direction of figuring out what a program is doing at a glance.
This is what happens when the program draws a Tic Tac Toe game:
Multiple arrows means that a method called another method multiple times (say, in an if clause or a for/while loop).
Methods that point to themselves indicate recursion. I think this one is more fun to look at than the program’s self-portrait above :).
The next step is to get the program to do this with variables, then to combine the methods picture and the variables picture together. The result, in my wild imagination, would be an easy way to debug programs when the problem is confusion between the methods or a variable pointing to the wrong place at the wrong time.
Also in my wild imagination, drawings like this make it easier for relationship-organizing brains to read, and even write, programs.
A massive, massive thank you to Gregoire Lejeune and his team for the Graphviz gem that draws the pictures that this program generates. The project would have taken much more time (and blood and sweat and tears) without that useful tool.