Tag Archives: tools

Unix Dying? Ha!

Julie Sartain over at Network World published a piece today called “The last days of Unix.” In, largely citing Gartner analysis, she posits that Unix is slowly dying.

To that, I say, “fat chance.” Reading the article, the numbers are reasonably compelling, but I think they tell a different story than what Gartner and Sartain are saying.

The article appears to be measuring pervasiveness through expenditure, and particularly server expenditures. By that measure, Gartner’s data is showing the levels have peaked and will slowly be declining over time. And generally, that measure is probably accurate.

But that’s a little like saying carbohydrates are going out of fashion because some Panera Bread franchises are closing. Measuring Unix’s staying power through people purchasing specific servers is probably not the best way to do it.

If you are trying to get a true measure of Unix’s pervasiveness over time, it would seem to be far better to look at shipments of…Unix. And it’s variants, of course (although the article differentiates between Unix and Linux, et al, it seems a bit of a spurious distinction). So look at the dedicated server shipments, sure, but also at Mac OS X (hello, Unix kernel), and RedHat/Fedora and CentOS and Debian and Solaris and …well, you get the idea.

Looking only at the sales of big iron itself says more, I think, about the decline in purchasing of big iron. Recent articles in mass media have talked about the slowness in tech spending, driven in part by companies’ move into the cloud for computing power. Well, that’s one example (of several) where previous orders for big iron just aren’t happening anymore, unless you’re someone like Amazon or Google – and they both build their own custom boxes.

So for those denizens of bash, the wizards of tcsh and the valiant vi users, fear not. Rumors of the death of Unix appear, to me, to be greatly exaggerated.

Retro Tech: The 200-year Old Computer

It was nearly 200 years ago (okay, 191) that Charles Babbage came up with the design for his Difference Engine, a mechanical calculator that could solve polynomial-based equations. In the 1820′s, he also sketched designs for a printer to go along with it!

What’s perhaps more amazing is that when, in 2000, the printer and difference engine were built, they worked perfectly. And they still do!

As we move ever faster into quantum computing, wearable computing, holographic interfaces, and all the rest, it’s sometimes useful to take a moment and look back. This week, to look WAY back, and celebrate one of the foundational moments of the technology.

The Computer History Museum in California has a working Difference Engine No. 2, and also has a wonderful interpretive website about it all.

Worth checking out!

Know Thy Tools

A while ago, I was reading an issue of Dr. Dobb’s when I came across the assertion that programmers waste a significant proportion of time because they don’t know their tools well enough. And I think that’s probably right. But it doesn’t go far enough.

Earlier on the blog, there’s a post about the importance of having a broad and deep toolset. But both the Dr. Dobb’s comment and the earlier post focus on the development side of things. I think the assertion is just as true on the design side as well, although the perils may be a little different.

When developing, if you’re working in an IDE and you don’t know the intricacies of how it works, you’re definitely going to be working more slowly than you need be. When designing, if you’re working in a design tool and you don’t know the ins and outs, you’re restricting the scope of your creative output. That’s perhaps an even more catastrophic outcome!

Think about Photoshop, for instance. That tool is both broad and deep, and it gets moreso every cycle. Now that it will largely be available as a subscription only, the changes will just keep on comin’. But if you don’t know how the filters work, you may no longer have those design choices in your visual vocabulary to work with.

In contrast, if you don’t know how to do multi-file grep-based search and replace in BBEdit — something that is roughly comparable in terms of complexity and importance, I think — you have a bunch more work to do to get to the outcome, but you can still get there.

Regardless of the specific poor outcome, the lesson remains the same: know your tools. Whether you’re an information worker who lives in Word, Excel, and PowerPoint; a coder who lives in emacs, BBEdit, or Notepad++; or a designer who lives in the Adobe or Corel worlds, you’re probably missing out.

Besides, how can you complain about the limitations of your toolset if you don’t really know what they are? Think of the fun you’re denying yourself!

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.