Tag Archives: coding

Getting Better (Or: We Used To Be Worse)

I’m a bit of a pack rat. Somewhere, I have encomia that goes back decades. And in the digital world, this is true as well.

So when I got a new computing device recently and needed to migrate a bunch of data, I had an opportunity to look back at projects we’ve done over the years, and that I had done for at least a decade before. What I found wasn’t all that surprising, but it was instructive.

Starting with my early work, it was, well, fair. I mean, it worked and all (in fact, one web application I wrote a decade ago is still in production use on a public website – think about how much on the web has changed in that time!). But it wasn’t coded all that well, and the emphasis was on getting it done quickly and briefly. (In other words, the code was hard to read and not well documented.)

Then I look at a project from five years later, and it’s all different: sure, sure, it works – that much is the same. But under the hood, the code isn’t just quick, it’s efficient. And there are actual comments throughout. The front-end design and the ‘look’ of the work is leagues better (by that time, I didn’t do it myself, and we had a team with expertise in that area). It’s a professional product.

Then I turn to a project we finished last year, and it’s more advanced yet. The amount of growth isn’t as dramatic, but it’s still there. Development patterns are being used effectively and both programmatic and business logic is easily intuited from the code (and its documentation), and the separation of functions allows for easy manipulation of pieces and parts. It’s a great result.

This progression is hardly unique, I think – every person and every firm, if they’re stretching themselves and striving for self-improvement, has something similar. But we don’t talk about it much, because we worry that clients (or, more specifically, prospective clients) think “we get better all the time” means the same as “we aren’t really ready for prime time yet.”

But that’s pretty shortsighted thinking. Even the best sports pros are always working on their game. We can always improve – after all, that’s the whole point of professional development, right?

It was heartening to see that transformation over the last couple of decades. Who knows what the next project will bring?

Aspects of Love

Programming languages come and go at a frightening clip. Less often but still with some regularity, frameworks appear and disappear as well.

But it’s more infrequent that entire approaches to coding come along. Functional programming has been around forever. Object-oriented programming has been around nearly as long. But it’s only been a little more than a decade that the idea of <em>aspect-oriented programming</em>, or AOP, has been on the scene.

If you’re not familiar with AOP, some background might be helpful. A key idea behind AOP is that there are functions that your code needs to do which go across (or cross-cut) the entire application. In other paradigms, you then need to code bits of those functions all over the place. But in AOP, you do it only once.

One prototypical example is logging. If you’re writing an application that does anything significant, you probably write out to some kind of log when it happens. In a user-based application, for instance, you probably want to log every time you add a new user or delete a user.

Under other approaches, you need to call some kind of logging hook in your addUser and deleteUser functions (or methods). But with AOP, you can define a separate logging function, and tell it to attach to the deleteUser and addUser functions. The parts of the code that actually do the work with users aren’t touched at all.

Why is this helpful? Well, suppose you want to change how logging works or how you call the logging piece. You’d need to touch every place it’s called. With AOP, you just change the logging piece once, and you’re done.

Or suppose you decide well after the design stage that you want to add a layer of security to every user routine to make sure the person trying to make a change has permissions to do so. You could go find all of the functions and add calls to them, or you could just create a security-check routine and attach it to the relevant functions.

Compiled languages like Java and C++ have had this idea for a while now, but it has been slow to come to interpreted languages. With the Flow framework, for instance, PHP now has AOP capabilities. There’s still some roughness around the edges, but it’s a big step toward widespread adoption of this approach.

Watch this space…

Retro Tech: Beagle Bros

Back when I was trying to figure out this whole technology stuff, The Great Migration happened. For me, that was the migration from a mainframe you had to drive (or, in my case, take the bus) to see and use to a computer you could just go to your room to use. And my first computer (before the TI, before the CoCo, before the C64, before all the rest) was an Apple ][.

Now this is not the time to rhapsodize nostalgic for the Apple ][ per se. But the environment around that computer encouraged hobbyists, students — and it encouraged fun. And one of the leading fun-makers was a software company called Beagle Bros.

They were weird. They were fun. They were whimsical. They’d put code snippets or bits of hexadecimal in their ads that would reveal funny lines, or a previously unknown feature in the computer’s code. Their whole purpose seemed like it was to enable hobbyists to dig ever deeper into the machine and get ever more out.

Take, for instance, their Apple Mechanic software. With it, I could create my own shape tables to use in my little hobby games. I could make ‘em look like they were professionally done. And this was in 1982!

Who else (before Clarus the dogcow) could teach you how to make your computer moo? (CALL 985, by the way.) Who else released so much professional software that was unprotected with code listings available, so you could see how it was done and try it yourself? Who else ran their own comic strip in their catalogs?

And perhaps most tellingly, who else had a software company (now gone) that inspired its own online museum? There aren’t many. And few had as much an impact on an entire generation of today’s programmers.

Perhaps it’s nostalgia, but Beagle Bros was ahead of its time in creating and putting forth a culture that engaged its customers (contests, for instance), respected them (no copy-protection, just a request not to pirate), and supported them (the PEEKs & POKEs poster alone was huge support). Many a company today could take a page from their playbook.

The Rise And Fall Of Programming Languages

Everybody out there who is fluent in conversational Latin, please raise your hands. (Peering out) Not many. How about Esperanto? Perhaps a few more, although you all seem to have shaggy beards and a perpetually quizzical expression. (Not that there’s anything wrong with that.)

Human languages come and go, even though they are so closely identified with a people. There are efforts to keep them going wherever possible, and records indicate that there may be as many as a thousand or more so-called “endangered languages.”

So it should come as no surprise with the pace of technology that there are endangered programming languages as well. Some, like B, were stopgaps until something else came along. Others, like COBOL, were historically important but really aren’t around much today (other than a lingering small group).

When does a programming language become pervasive enough to get interested? And when does it wither enough in ubiquity that it’s no longer relevant for a project? Both are tough (and squishy) issues.

In terms of the upswing, my bias is to get interested pretty early in gestation — not necessarily to use the language for a client project, but to get a sense about where language (and compiler) development is going. I’m not likely to use Ada or even Haskell when building something that others will need to maintain, but, as an example, looking at how Haskell handles lazy evaluation and “first-class” functions is fascinating, and broadens the knowledge of the team.

So perhaps the better questions are about when to use a language for a project that will be released into the wild — and when to stop doing so, as a language’s star is falling? The answers to both are really the same: when maintenance and long-term expertise is easy and relatively cheap to find.

We’d love to be in lifetime engagements with clients. And many of our clients are with us for many years. But we don’t assume that, and we don’t want to build something that will create hassles for the client later. So that means, no matter how much we love Forth, we’re probably not going to use it to build a web application. There just aren’t enough people out there to support it. (Plus, that’s not really a great use of the tool.)

But let’s take a tougher example: perl. Fifteen years ago, it was everywhere. If you didn’t know it, you weren’t considered serious about building for the web. As PHP has usurped some of that space, perl remains a widely-used language (although more and more, it seems to be confined to the back-end and server side).

But man, I love perl. It has an ability to work with bits of data and patterns that is perhaps matched, but rarely surpassed. Contrary to some of its reputation, it can be elegant — but it doesn’t force it. (Why is there so much bad perl code? Bad perl coders.) And the CPAN archive of modules and third-party libraries is peerless.

What to do, then? Objectively, perl’s fortunes are falling. Has it passed the threshold of use on a major project? Well, as of this writing, I’d say no — but it’s getting close. The thumb on the scale that balances cost-benefit of using a language for a project is getting kinda heavy. It’s probably in the space where we will build and maintain perl-based projects that are already in that language, but are unlikely to starting something from scratch in it.

Which is sad, but for every one of those, there’s an Objective-C or a C# that’s climbing up the charts. Goodbye Esperanto, hello Mandarin.