Tag Archives: languages

Data Structures Are Dead…Long Live Data Structures!

Eons ago, when I was first learning how to code, we spent a fair amount of time focusing on data structures at the heart of development. In that time, both memory and fixed storage were expensive and scarce, so by learning how the base structures worked (and learning how to code them up from scratch), we could pick the most economical version and save an extra kilobyte of memory or two — a precious commodity!

These days, neither memory nor storage are terribly expensive nor scarce (although in our networked environment, there are still reasons to conserve). So it may not be much surprise that there are many programmers who couldn’t write an implementation of a doubly-linked list or b-tree.

Yet it’s not stopping them from being productive, great developers. Why? Because in today’s framework and higher-level language-driven world, those lower-level structures are often abstracted away or handled behind the scenes. Take Cocoa, for instance, which has classes for arrays, sets, dictionaries, and more — all with optimizations and methods to do querying, modification, and more built in.

Sounds like unbridled progress to many, and I certainly agree with the ‘progress’ part. But unbridled? I’m not so sure. I continue to think there’s value in knowing how the fundamental data structures work — for at least two reasons:

First, in knowing the internals, you can make more informed decisions about which to use when. With Cocoa, for instance, Apple has released a whole set of tech docs about the best uses for each of the “collection” types. It’s helpful and well-written, but mostly superfluous if you have the underpinnings needed to internalize that kind of thing.

Second, there’s still a role for optimization. Hardware and networks continue to get faster and frameworks continue to get more efficient — but it is poor form to rely on those increases when you don’t have to. And to optimize, there’s really no substitute for knowing the basics of how things work.

So maybe we’re seeing the slow erosion of understanding about low-level data structures like stacks, queues, and heaps. And for some, maybe that’s OK. But I’m not ready to see them go just yet.

Finally! finally in PHP 5.5

PHP 5.5.0 was released yesterday, and there are a handful of helpful new features. Among them, there is one that looks the best to me — the try-catch block has the finally block added. After all, if you’re doing exception handling in your code with try-catch (and if you’re not, you really should be), there are often scenarios in which you want to execute some arbitrary code at the end of the block, regardless of whether an error got thrown or not.

In some cases, you can put it outside the try-catch block (at the end, of course), but there are at least two circumstances where that’s less-than-optimal. First, if the program flow is altered in the try or catch, yet you want to tack on some code at the end, you’re in luck. But in our case, most of the time, it’s a readability issue. We try to group code conceptually when we write, much as we do when writing in English. That means we use sentences and paragraphs. Well, when coding, we do the same thing. And the addition of the finally block will make that even easier.

Another nifty functional help is the addition of the list form in foreach structures.If you work with nested arrays, you can now unpack them in the foreach construct, exposing the underlying variables much more easily. Like the finally block addition, it’s not as though you couldn’t code around this limitation, but when you don’t have to, code gets more readable.

In a deja-vu moment for C programmers, you can now dereference arrays and string literals to access specific items and characters. So in PHP 5.5, ‘Square’[1] equates to ‘q’. Not too shabby.

You can now pass a function call to empty() to evaluate it, which is another keystroke-saver when coding. So if you have a function foo() that may return data or may return, say, false, you can evaluate empty(foo()) and see if false came back. Again, a minor assist, but an assist nonetheless.

There are other features in this release, too, including a new Zend optimization caching extension, some enhancements to the GD graphics library, a new yield keyword that allows you to do simple iteration without using as much memory, a class function that gives you the unqualified class name, and more.

It’s good to see PHP continuing to evolve and grow — it has come a long way since I first used it fifteen years ago!

The Evolution of HTML5 (and the Browser)

The grandly-named “Global Developer Survey” was released recently, sponsored by Kendo UI (makers of an HTML5 framework). As you might imagine, it focuses entirely on HTML5, and presents a fairly rosy picture.

They surveyed 5,000 or so developers from around the world and asked them about their use of HTML5 — what kinds of apps they build with it, which parts they use the most, what kinds of platforms they target, etc. Given the sponsor, it’s no surprise that more than two-thirds of respondents believed that HTML5 is important for ALL developers. Color me a little skeptical at that, but we’ll move right along.

But one part of the results that stood out to me was the focus of app development efforts by the surveyed developers: 60% were targeting desktop apps, while 26% were targeting mobile and 14% tablets. When asked what kind of software specifically the devs were building this year with HTML5, a whopping 87% said desktop websites/web apps, while only about half said mobile websites.

This generally tracks web traffic by platform (as of May 2013, in North America, only about 12% of web traffic was from a mobile device), which may make this more ho-hum. But it’s that ho-humness that is surprising. It has only been in the last version or two of most major browsers that HTML5 support has gotten more robust. The majority browser on the desktop, IE, still doesn’t support over a third of the spec! Meanwhile, support on mobile platforms has been more robust for quite a while.

Perhaps this gives hope that with so many HTML5 developers working on the desktop, the desktop browsing environment will get better for HTML5 — and, one hopes, more nimble in general, with the pace of adopting newer standards (3D Canvas graphics with WebGL, anyone?). And there are some signs that this is happening, albeit glacially. Chrome is poised to be the biggest browser on the web in North America any minute now (it’s almost tied with IE as of May 2013′s statistics), although the recent jump in browser share has been so sudden that it’s hard to know if it’s an anomaly.

Kudos to Kendo UI for sponsoring such an extensive survey, even if the participant selection was skewed. It would be interesting to get a more generalizable swath and see if the same desktop/mobile dichotomy holds true in other technologies (e.g., Java, Objective-C) as well.

Getting a Plumber’s Crack

Before it became hip-hop fashion, it was uncommon to see someone walking around with their belts hanging down below their waists. And this is a good thing.

The only exception: the plumber. Weighted down with tools in his or her belt, the mental image of the plumber bent under the sink with their belts tugging down is inescapable (no matter how much you may want to scrub it from your brain). But when it comes to programming, it may not be a bad thing.

Virtually, that is. After all, the plumber’s belt is weighted down because of all the tools available. Shouldn’t the programmer be in the same situation?

Lots of programmers have a core comfort with a single language, or perhaps a couple of them. Outside of those, though, they may be more lost. But who needs ‘em, right? If you know one or two languages in depth that will do the job, why do you need more?

One reason goes to how we learn. When we learn new things, we attach it to a framework of whatever we already know. So the more we know about a topic, the easier it is for us to figure out how new information ‘fits in.’ If you already know how certain structures work in one functional programming language, you can probably figure out how they work in a different one. The difference, largely, is syntax. So adding more languages to the arsenal means the cost in adding another gets smaller.

Another reason for learning several languages is the hammer-nail problem: If all you have is a hammer, everything looks like a nail. If you are rock-solid in imperative languages like C or Pascal, you will tend to look at problems in a way that can be solved procedurally. But what if a problem can be solved more quickly using an object-oriented language like C++ or Java? It’s less likely you’ll be able to spot that (let alone do something about it).

Around here, we require our developers to be highly-proficient in at least two languages, and conversant in several more. We even have an internal programming competition, where each challenge is a different problem–in a different language. One time it might be C++; the next, it might be Python. It keeps everybody on their toes, learning and developing their skills and perspectives. A highly-recommended practice.

But we still out-source the sink repairs.