Category Archives: Development

Retro Geekiness: Sorting Out Sorting

As a child about thirty years ago, when I decided to transition from computer programming hobbyist to student, one of the big topics that represented that transition was algorithms. These “recipes for the computer,” as I was taught at the time, were the key — the secret to unlocking the potential of this great technology.

One of the first areas of algorithmic exploration I embarked on was sorting algorithms. Which, although it was probably a pretty haphazard selection, turned out to be a good choice. Even now, three decades later, knowing how sorting algorithms work and when to choose the right one comes up all the time.

But back then, it was a brave new world to me, and I was just trying to figure out how they worked at a basic level. It was a struggle — I knew that some were faster than others in certain cases, some really sucked all the time (using the vernacular of the time), but I was having a little trouble grasping the nuances.

Then one day, while I was idly flipping through my school district’s central film and video catalog (the depth of my geekiness as a child is unending), I saw — what’s this? — a video about programming! I quickly badgered the librarian to request it, and when it came, I beheld: Sorting Out Sorting.

This 30-minute video was created entirely on the computer in 1980 — an impressive feat by itself — by the University of Toronto. And it remains, I think, the best teaching material on sorting algorithms in existence. When I started teaching computer science, I went on to show it to several classes of students over the years, and while it’s certainly dated (oh, man, is it dated), the information remains stellar.

There really is no substitution for seeing the algorithms in action. These days, there are websites like this one that show you much of the same animations in a browser window, but the movie gives you more in-depth detail about each one.

This is by no means a film review website, but this is one I’d give two-thumbs up. Put some legwarmers on, turn down the Huey Lewis & The News for a minute, and check it out.

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.

WWDC 2013: Getting Out of the Way

Apple’s Worldwide Developer Conference wrapped up last week, and amidst the announcements about new user-facing features in the next versions of iOS and Mac OS X (versions 7 and Mavericks, respectively), there were a ton of announcements and sessions about new developer features as well. A new version of Xcode was featured, along with a slew of new and revised APIs.

As I watched the sessions related to one of those APIs, Sprite Kit (which is a pretty amazing new gaming engine that includes physics, particle effects, and 2D graphics awesomeness), an offhanded comment by the presenter resonated with me. The intention of the new toolkit (and, ya gotta hope, other changes) is for the technical environment and hurdles to fade into the background, and to make the execution of the content as seamless as possible.

The point is to get out of the way.

It’s a worthy goal, and certainly by eliminating the need for some game developers to deal with a third-party toolkit, I’m sure Apple has made some headway there. But thinking more broadly, there’s still a ways to go.

Think for a minute about a technologically-proficient non-programmer who wants to build an app. What are they to do?

Learn a language (in this case, probably Objective-C), learn a development environment (e.g., Xcode), join the developer program, and learn the APIs. While there are many people who are doing just that, it seems like there are ways to better get out of the way.

For some examples, we can look to history. In the earlier days of the Mac, there was HyperCard. Bill Atkinson created the visual hypermedia authoring tool nearly 30 years ago, almost a decade before the WWW showed everyone how powerful hyperlinks could be. With HyperCard (and its successors, including SuperCard, which is still shipping and works on current OSes), an elementary-school student could create an app. Little to no formal “programming” — just point, click, and develop.

For more sophisticated applications, there were graphical development environments like Prograph (now resurrected as Marten). In these IDEs, you still need a knowledge of the APIs, but you string the calls together graphically, with your custom functions and routines represented as graphical units that can be strung together. It requires more knowledge than HyperCard, but definitely less than the current standard toolsets.

But back to the present day. Programming is still a niche skillset, despite the ubiquity of technology in our lives. Students in middle and high schools are showing middling interest at best. One (of many) reasons that’s true has to be the lack of an easy way to get novices building sophisticated apps. The tools and processes are just too much “in the way.”

Apple’s moves in the direction of easy and sophisticated development are admirable. But there’s a long way to go to realize the promise that Atkinson made back in 1985.