Why Magic Is Good, But I Still Complain

Programmers are lazy.  Face it, if we wanted to do ‘real’ work, we’d be out in the hot sun, breaking rocks with pickaxes.  Or maybe in front of a blackboard, using chalk to solve equations.  Oh, the horror!  The humanity!

We want an easier life, and we’re willing to work for it.  In fact, that’s the entire point of our lives — to make not just our lives, but everyone’s lives, a little bit easier.  A little bit better.  Reduce the amount of paperwork…  even if it’s just by moving it to the computer instead.

As such, ‘magic’ in code is good, great, grand.  If I don’t have to manually explain that the url foo.com/bar/12/ needs to find the bar object with id of 12, that’s great.

My complaint with the programming language I’m taking a class in — lets call it, oh, ‘Emerald’ — isn’t that it provides me with a lot of magic.  My complaint with ‘Emerald’ is that none of the introductory documentation explains the magic.  It just says do XYZ and magic happens.

Magic is great.  But I need to understand enough of what is going on to actually learn from it!  I don’t need to learn ‘type XYZ to get Z to happen'; I need to learn enough to get my own event, Z2, to happen.  More than that, by understanding what is going on, I might actually remember it when I need to do it myself.

Why does autocomplete exist?  So that we can focus on learning concepts… not memorizing the constants that support them.

PHP Interfaces — Why Use Them?

In PHP, an interface is nothing more than the ‘skeleton’ of a class.  You can’t put any non-public code into it, you can’t add properties, or otherwise add functionality.  It doesn’t in any way help with the normal approach to abstraction, wherein lower level classes handle details so the higher level ones can focus on other things.  In many ways, it seems an absolutely pointless idea.

In and of itself, you could make that argument.  Interfaces don’t ‘do’ anything on their own other than add restrictions to your code.  If you implement an interface, you’re required to add all the required methods — even if you don’t think some of them are needed or make any sense.

The real ‘power’ of an interface isn’t in helping to re-use code, it’s in the fact that it’s a ‘contract’ that your classes are obliged to fulfill.  Yes, it requires more work, but it’s work that’s designed to help the programmers.  As my immediately previous post about Objective-C points out, with more powerful compilers and computers, we have the option of backing away from having to work and think like a machine would.  Instead, we can focus on things that machines can’t do — like create logic that is suitable to a task.  Interfaces are a language level tool to help us do that.  They provide the framework that tells us we need to complete a given set of methods, which allows auto complete to fill in calls to those methods even before we finish writing them.  They actually improve code-reuse by allowing us to focus on a specific set of code, while leaving other details to the implimentor.  A plugin can simply say ‘give me a class that fulfills this interface’ and proceed on using it, not knowing or caring how you fulfill your responsibilities — be they saving data (to a disk, a database, or remote server), or actually sending the text message you just created.

In a sense, Interfaces allow you to invert the normal inheritance approach towards abstraction, defining lower level tasks without worrying about big picture items.  Your interface lets you say ‘OK, I’ve done this work for you.  Now, I need you to save this file to disk to retrieve later’.

In some cases, this could be done through the use of abstract classes.  That’s also a very valid approach.  But the use of abstract classes enforced a hierarchical decision, whereas interfaces allow for ‘sibling’ classes that don’t interact at all, except via the interface.  It’s a tool, no more and no less.  Use it as appropriate, don’t use it when another tool fits better.

Adapt Languages to People, Not People To Languages

I recently read an blog post on how to make binary branches in a function definition more readable.  In and of itself this is a laudable goal, but frankly I think it’s completely backwards.

Instead of trying to find ways to use a given programming language in a more readable manner, focus instead on developing a new paradigm for programming syntax. The majority of languages are so similar that the syntactical differences are largely a matter of learning the appropriate keywords and to use a period in place of an arrow (the -> you see in C++ for example).  Python is more or less identical to C++, just with a slightly different way of expressing the exact same concepts, and a different way of typing out various STL features. The implementation is different, but the underlying logic behind the syntax remains the same.

Objective-C is my preferred language whenever possible because the developers actually took the time to consider how humans think, and then programmed the language to work more naturally with us. Instead of changing your code to make it easier to read, the changed the language.

The only real ‘downside’ to their approach is that it isn’t just object-oriented, it actually requires that you use objects if you want to gain the benefits of the language. And, to me, this is *not* a downside. OOP has proven itself a superior paradigm for most programming efforts, so enforcing it’s use just makes sense, even if it does require a degree of ‘magic’ to get started with.

I don’t care how you try to pretty it up; runSomeLogic(account, person, TRUE, FALSE); is always going to be harder to read than [account runSomeLogicWithPerson:person usingCache:YES withSecurity:no]; It’s just… human nature. The self-documenting function of the Objective-C method name is a huge mnemonic aid, and the only downside to it is the extra typing required. And that downside is easily solved by the incredibly helpful feature commonly reffered to as ‘intelisense': the ability of an IDE to guess what you’re trying to type, and help you finish it. That feature may be a ‘crutch’, but it’s a crutch that is far more helpful than harmful. In my experience, maybe one time in ten the reason intelisense can’t finish for me is because I made a mistake typing out a function or variable name (and almost invariably it’s because the function or variable name isn’t following standard conventions). The other nine times, I either had an error elsewhere in my code that was causing intelisense to be confused, or I had a data-type mis-match.

In the end, I’ll choose Objective-C over other languages precisely because, whether it’s wordy or not, it’s easier to read and understand.  The hard work of programming isn’t typing, it’s understanding what to write and then fixing the mistakes you’ve made.  Anything that helps in those two goals, even if it requires extra typing, is a huge aid.

Old Solutions For New Problems

About a year ago, I wrote a quick little program to help the judging process for the 59 Days Of Code contest.  Please note that I need to emphasize the word ‘quick’ before I go any further, and that’s a word that should scare any professional programmer.  It’s alright to write a ‘quick’ prototype, but trying to do anything that needs to be production quality ‘quickly’ is a dangerous idea.  Testing is important, not just to catch the bugs you expect, but the bugs you don’t expect.

In the case of the program in question, we had an issue where somehow the data stream between device and server was corrupted.  We had all the original data stored in logs, but trying to sort through JSON strings stored in a log is a time-consuming, annoying process.  It’s technically doable, but as I rapidly realized on the day of the event, trying to do it on the fly simply isn’t practical.  I needed to have already written or found an application to help handle the process, and I hadn’t.

But restoring the data, while important, isn’t half as good as preventing the corruption.  Towards that goal, I hope to re-write that software this year to do two things different.  Firstly, devices won’t download data from the server willy-nilly in an attempt to ‘just work'; they download on request only.  Secondly, I need some way to make sure the data gets to the server in good format.

The question of course, was how?  I could have dug in and done some research on the problem, and oh boy oh boy are there a lot of solutions out there fore it.  But when the opportunity to re-write the software was first discussed, I didn’t have the internet handy.  I had to rely on what I already knew, and for some reason verifying messages against accidental corruption isn’t something I really learned in school.

And from that quick solution, come up with in about 5 seconds of thought while on the phone, comes the point of this post.  I didn’t learn anything about how to handle accidental issues, but something else came to mind: when studying security, I learned several techniques to handle man-in-the-middle attacks.  Sure, the cryptographic portions of those techniques would be a pain to manage, but the basic underlying concept didn’t necessarily need to apply against an actual ‘attack’.  Having the packet become malformed between device and server is, in a very real sense, a ‘man in the middle’ attack by random chance.  And since I’m worried about random chance, not an accident, suddenly I have a solution.  Just take the basic message, generate a simple, non-cryptographic MD5 hash, and voila!  Message integrity checking made ‘easy’.

The point of this, of course, is that I took an old solution for a different problem, and re-purposed it to a new one.  The fact that historically speaking, the solution for security probably evolved out of the solution previously used for verifying data integrity is simply a rather amusing joke on me.

The ability to take a new problem, and use an old solution, is important.  In programming, old does not automatically mean bad.  Sure, A* pathfinding isn’t as cool or good as flow pathfinding; for the context of a game with many units I’d probably pick to implement flow any day of the week or twice on Sundays!  But if I’m writing a GPS program, A* is probably still a better route to take, because my concerns regarding other ‘units’ (other cars on the road) can be better expressed by modifying the relative weight of various connections between nodes on my map.  More than that, some day I might find that the basis of the A* algorithm could be useful for something else entirely.  What, I don’t know.

The only knowledge that is ever wasted is knowledge you forget because it’s ‘useless’.  Maybe it doesn’t apply immediately, but keep it tucked away somewhere.  Maybe you can use it somewhere down the line, for something totally unrelated to it’s original source.

Bit Length: Making A=B cause A==B evaluate false

I was hoping to my make my first ‘real’ blog post something interesting and useful.

Instead, it’s going to be a laughing rant over the wonders of bit lengths.

Once upon a time, it was necessary to count every byte of data you put into something.  If an 8 bit number served your purpose, you used 8 bits exactly and tried to shave some memory out elsewhere.  You didn’t use 16 — or higher — bit lengths unless you really needed them because every last bit was precious.

These days, we’re mostly past that.  We just say ‘int’ and be done with it, without really thinking about how wide it is.  After all, the default of 32 bits is huge, and while some applications can hit that limit, many, many more won’t.  (And with 64 bit OS’s becoming more and more common, I would not be surprised to see the default int length become 64…).

So, when I created my Core Data schema, I picked a nice, sensible 16-bit length.  Given that I was transitioning from storing a version date to a version number, it made sense.  We’re not going to have hundreds and thousands of versions of an ad.

Unfortunately, the server side of the code hasn’t made that transition yet.  The server-side code is based on date, still, and the datetime values are reduced to a 32 bit unix timestamp to transfer them to the device.

Unfortunately, the 32 bit value is larger than the 16 bit address space.  So I just spent several hours debugging code which reduces, logically, to the following:

//Do STUFF//

For some strange reason, I always got into the if block.  It was only after a long stretch of debugging that I discovered that the issue was the above code — at which point it didn’t take too long to figure out what the actual issue was.  Just… frustrating to get there.

Yet Another Blog… Why?

There are about as many programmer blogs out there as there are programmers. Why? Why is running a blog a ‘requirement’ to being taken seriously as a programmer? I can’t provide definitive answers, but I can share my own thoughts on the subject.

The first and obvious answer is that it’s expected because it’s expected. After a certain point, traditions and ideas take on a life of their own, completely outside of their original purpose. We can point back at history and show where they started, maybe even why, but their relevance fades to ‘it’s tradition’. As reasons go, this isn’t exactly a bad one. In every profession there are rules to follow, in every job there are things that need doing. Much as you can’t get a decent job without a college degree, whether or not that degree relates to the job, you need a blog to get anywhere as a programmer. Why? Because it’s expected. Why it’s expected is often not even thought about.

But that’s not enough for me. Well, honestly, I suppose it is — would I be starting this blog if I didn’t want to get somewhere as a programmer? But I like to know the ‘whys’ behind traditions, to understand what their reason and purpose is. The college degree one is easy; it proves that you’re willing to work, to learn, to grow. A couple of years job experience can show some of that, but you’re getting paid to work at a job. You pay to go to college. It shows a desire for self improvement. It shows an ability to work at something with no hope for immediate payoff.

So what does a blog do for a programmer?

First off, it can be a great notepad for past achievements. Find the solution to a difficult, odious problem? Blog about it! Now the next time you run into the problem, even if you’ve forgotten the solution, you still have a record of it! And better yet, that record is public, so maybe you’ll help someone else some day. Remember, we stand tall because we stand on the shoulders of the giants that came before us, it’s important to pay that forward by letting others stand on us.

It also helps you make certain you’ve really solved the problem. Writing a blog article about something forces you to articulate the issues at hand and really consider them. Half the time when I hit StackOverflow, completely confused and bewildered by a problem, I get halfway through explaining it before I get hit by sudden inspiration. Maybe the inspiration is a solution, or maybe it’s just more wasted time, but because I forced myself to sit down and lay my thoughts out in ordered form, I got an idea. Similarly, writing a blog article will force you to think about your solution, and make certain you understand it. A solution you don’t understand is as useless as one that just plain doesn’t work. If you don’t understand why the solution fixed the problem, you can’t even guess at whether you’re just masking a symptom of a deeper underlying problem. Bugs can propagate across an entire program before becoming obvious, causing issues in a place seemingly unrelated to the actual bug. If you just fix those issues, the bug is still there, waiting. Better to track it down to it’s source and fix it there.

As an extension to that principle, teaching something is a way to make certain you really understand it. When you teach something, you’re forced to go back over the entire thing, even the parts you think you already understand. This gives you a chance to look over the beginning again with a more experienced eye, and maybe improve your understanding of the basics a little more. And programming, despite all the tools we use to break it into pieces, is fundamentally holistic: you have to understand everything, or you understand nothing.

In addition to actually making you a better programmer, it also offers your potential employers something else. It gives them an opportunity to gauge your skills, abilities, aptitudes, and attitudes outside of the dreaded, stilted confines of a job interview. It’s an opportunity for them to look not at what you want them to see, but at the real you. When you go to a job interview, there are a thousand and one rules that define the situation, that limit both you and them. You’re expected to be calm, to appear completely and utterly professional. Yessir, nosir, threebagsfullsir. You’re exchanging information, but it’s also a performance worthy of an actor. The blog is a place where they can look past that acting to see the real you. You want it to look professional, well reasoned, and productive, but you aren’t confined by the rules of a job interview. It’s a chance to see past the (probably metaphorical) suit you wore to the job interview.

So that gives us four good, solid reasons to run a blog. A chronicle that can help you and others solve an issue when it crops up again; a way to force you to think through the solution; a way to help you deepen your understanding of it; a way to show yourself off in a good light. Each of those reasons is valid. Each of those reasons is important. But taken together, I’d say they make an incredibly persuasive argument. But the fun part is that’s just the reasons I can (and did) come up with. There are others out there. They might argue that it’s about learning to write for human beings; that it provides for a sense of community; that it’s how we provide for the education of programmers. If you spend the time to look, there are thousands upon thousands more reasons.  (Mind you, not all of those reasons will show up in articles that are about those reasons; two of those links are to articles where the argument is a sub point of the real article.)


That brings us here.

Time for me to start start filling the communal pool of wisdom, not just drawing from it. Time for me to learn by teaching others what I know. Time for me to show off for employers, because as much as I’d love for my current job to last forever, what are the odds of that? (Actually, pretty good I hope… but I’ve never liked the idea of keeping all my eggs in one basket!)

I don’t know how often I’ll post here. I don’t know what the average post length will be — though I don’t intend to have very many one-or-two liner blog entries. There’s a lot I don’t know. If you’d like, you can join me as I go learn some of it.