Category Archives: Computers

Computer Programming Ducks

Time to start talking more about programming. It’s one of my defining aspects. I’ll try to make it as interesting as possible for the non-programmers. For the programmers, I’m sorry, but that means sometimes I’ll have to get a little basic or skirt a few corners. Feel free to use the Comments section!

True computer programmers, the ducks taking to the water of making software, are their own special kind of odd duck. Life is filled with different ducks: sales ducks, art ducks, factory ducks, music ducks. Lots of ducks. I’m just saying that computer programmers float in a different part of the pond.

I know this because I’m one of the flock. I have been for over three decades. That’s right; I’ve been doing this since before some of you reading this were born. It would be nice to believe I’ve figured at least some of it out by now. Feels like I know a thing or two. One thing I’ll say: I do know this part of the pond. Been here a while!

Software: It’s just zeros and ones

Software is an abstraction of a process, for instance a calculator process or a spreadsheet process. It can be the abstraction of the process of managing payroll or process operating a machine (even of flying an airplane). The process is also an abstraction. Knowing how to use a spreadsheet or fly an airplane is abstract. Actually doing it is concrete.

Software is an abstraction of an abstraction! And that’s my point: there’s a lot of abstraction in computer programming.

Physically software is just a long string of numbers. In fact, it’s really just a string of things and not things. Holes in paper; or not holes in paper. Magnetic domains magnetized; or not. Tiny electronic switches turned on; or not. You can represent software as a string of black and white jellybeans. It’s all the exact same thing. What matters is the pattern of thing and not thing.

The final product is created out of thin air and is nothing more than a string of numbers. (And yet it can do so much.) The final product is an abstraction filled with abstractions of its own.

Starting at the bottom, the string of ones and zeros form a complete package of information: a software application. The standard that describes how to organize the bits as a software application is an abstraction. The context for the bits is specified by the standard, so it embodies the encoding information needed to make sense of the bit pattern.

The bits themselves clump into small packages (bytes, or more properly, octets) of eight each, which is important for network transmission and storage. The whole octet thing is an abstraction. Not to mention the related UTF-8 and Unicode abstractions regarding bit clumping. Not to mention the abstraction of various computer hardware architecture.

Now the packages of eight bits, the bytes, are clumped into small groups, usually, of four (4 x 8 = 32). These are called words. In some cases, the words are of two bytes (2 x 8 = 16) or eight bytes (8 x 8 = 64). The phrases “32-bit” and “64-bit” refer to this is the level of abstraction. The software is a string of words now rather than just a string of bits. The words are meaningful in the (abstract) language of the program.

A computer program uses an abstract language to describe abstractions such as lists, containers and pipes. It uses them to implement the abstract design of the program. The implementation, the string of words, must be executed (run is the friendlier word) for the abstraction of the program to spring to life. The context in which the program is executed (run) is one more abstraction!

Abstractions on top of abstractions using abstractions to do something concrete.

Even our tools are abstract. Programmers are tool users; the good ones are also tool makers. And our tools are as abstract as our product. In fact, most tools are the product of some other programmer! The key tool any software maker uses is a software writing tool, but there are many important others: analyzers, debuggers, organizers and wranglers. Without them we couldn’t do our abstract job.

So it’s no wonder we’re a little different.

Software Design

Software development is hard to describe or compare, because it depends so much on the use of abstraction. There is a continuum of professions based on how much abstraction they tend to require from their workers. You may not realize the degree to which you use abstractions at work and in life. (But that’s a discussion for another time.)

Still, many professions focus on concrete objects: doctors focus on bodies; chefs on food. Police, fire, nurse, EMT, social workers of many types see people in need. Factory workers make concrete objects; salespeople sell them, marketers advertise them; technicians fix them; maintenance crews clean them and junk them. And that’s the short list.

Other professions deal more with abstraction. Architects and Mechanical Engineers, for example, deal with drawings and models, which are abstractions of buildings or machines. They start from a pure abstraction, the idea and design, and work to build a concrete thing. [In passing, computer models and 3D printers have made the abstractions much more concrete. We’ve come a long way since faded blueprints.]

Lawyers and accountants deal even more with abstraction; the books only record the abstractions of justice and cash flow. Even the objects of their professions, clients and businesses, can be abstractions. A corporation is an abstraction, but it can have lawyers and accountants, and recently it has achieved legal “person” status. At some point business and law come down to people; that’s where it becomes completely concrete.

Composers, poets and other artists are heavily into abstraction. As with law and accounting, the paperwork often just stands for the real product. Artists have in common with architects that they design a product from an idea. The final design is an abstraction represented as lines, notes or words on a page (or bits stored in memory). Architects go on to realize their design by building it; some artists build their design, others perform it (some may record the performance). In some cases, a book for example, the design is copied, and others bring the design to life by reading the text.

Mathematicians and theoretical physicists are entirely in the realm of abstraction! In some cases, 11-dimensional objects for example, a concrete object is not possible. Or took place long ago; the Big Bang took place a very long time ago! In other cases, the forces, energies or times involved are far beyond our technology. They could be concrete in theory, but we’re not likely to pull it off any time soon.

Software workers are similar to architects; they design from an idea. But once completed, the design is the product. Software is like a book in this sense. And like a book, it is read (or run). More than just read, the software design is performed every time you run that software. The software design that is your browser (Chrome, FireFox, IE, Safari, Opera, et alii) is performing right now, acting like a browser, which is how you can read this article.

Software Engineers

I don’t like the term Software Engineer. Real engineers have licenses and certifications and prescribed educations. No such exists (currently) for software makers. It is still a new craft in our society (it goes back only to the 1950s or so), and we haven’t caught up to how complex and demanding it really is. Anyone can use the term Software Engineer, so it doesn’t have the meaning it could.

The meaning it could, should, have is the same meaning as for Civil, Electrical, Mechanical and other Real Engineers. It should mean a prescribed area of knowledge and skill for anyone who would be an Engineer. Until software education and the software profession catches up with reality, I continue to resist the term.

Knowledge Workers

People who work with software are sometimes called knowledge workers, but I think that’s also poor terminology. All workers use their own knowledge as well as the business’s knowledge. Some professions require more base knowledge than others, but it is still a continuum. I just think it’s a vague way to specify a profession.

I’m fine with computer programmer, actually.

Maybe that’s low brow, but I like it. I’m fine with software designer or software maker (but not software engineer). Bit wrangler is a fanciful, fun term, although byte wrangler sounds a little more dangerous. You can’t really say you make holes in paper anymore.

I kinda like telling people I train silicon life forms.


Sideband #38: The Next Hill Over

Imagine standing on a very tall hill in middle of a thick forest. Your hill is tall enough to take you above the trees; when you look out over the trees, you can see for miles around you. Ahead you can see another hill sticking above the trees; this is your goal.

You want to reach that hill.

A question arises; you are asked, “How long will it take to reach yon hill? What will you need along the way?”

Continue reading


Sideband #35: Binary and Zero

The ship sailed when I was moved to rant about cable news, but I originally had some idea that Sideband #32 should be another rumination on bits and binary (like Sidebands #25 and #28). After all, 32-bit systems are the common currency these days, and 32 bits jumps you from the toy computer world to the real computer world. Unicode, for example, although it is not technically a “32-bit standard,” fits most naturally in a 32-bit architecture.

When you go from 16-bit systems to 32-bit systems, your counting ability leaps from 64 K (65,536 to be precise) to 4 gig (full precision version: 4,294,967,296). This is what makes 16-bit systems “toys” (although some are plenty sophisticated). Numbers no bigger than 65 thousand (half that if you want plus and minus numbers) just don’t cut very far.

Continue reading


Computer Programming is Hard!

Computer Programming is hard! It’s at least as hard as what commercial architects do, and I will argue that it’s as intellectually difficult as what doctors and lawyers do.

Many people think it’s easy, because they know some nine-year-old who “programs,” but there’s a difference between fooling around with the computer and building good software applications.

Here’s the deal…

Continue reading


Sideband #28: 2 ^ 64, ‘K!

I’d planned to do this later, probably for Sideband #64, but in honor of my parents 64th wedding anniversary (2 parents, 64 years, okay!) this numerical rumination gets queue-bumped to now.

Just recently I wrote about 64-bit numbers and how 64 bits allows you to count to the (small, compared to where we’re going) number:

264 = 18,446,744,073,709,551,616

That’s 18 exabytes (or 18 giga-gigabyes). Just to put it into perspective, if we were counting seconds, it amounts to 584,942,417,355 years; more than 500 billion years! (That’s the American, short-scale billion.)

Continue reading


Sideband #25: 64-Bit Address

A long, long time ago on a USENET far, far away, I was part of a debate that started with the idea that, even if we had disk drives with 64-bit addressing, people would still fill them up with videos, images and whatnot.

The idea grew from some of us old-timers reminiscing about our first brick-sized 5-meg hard drive and how we thought, “Gee, I’ll never fill that up!” (And look how that turned out; I have single image files that wouldn’t fit on that drive!)

The premise was that, even with seriously gigantic hard drives, we’d still manage to fill them and need more, more, more…

Continue reading


The Bug In The Machine

I’ve been a computer programmer for 33 years. Some of my early work is still stored on punched paper tape! And if this computer programmer has a particular skill, it is probably in the area of debugging.

Those who know me know I suffer from a life-long hearing defect and have, thus, grown up being pretty good at figuring stuff out based on scant evidence. This is precisely one of the required skills for debugging, and let me just say that I’ve gotten very, very good at it over the last 33 years.

But for the first time, I have an actual bug in my machine. An honest-to-god, six-legged thing crawling around in my machine.

Continue reading


Hello world!

“In the beginning was the Word, and the Word was…”

Many of you will recognize that as the first words of John 1:1 in the Christian New Testament Bible. There’s also a cross-reference to the very first words of that Bible (Old Testament in this case), “In the beginning God created the heavens and the earth.”

This is about words and about beginnings.

Others might recognize it as a conflation of the lead-in to a Moody Blues tune, OM, from In Search of the Lost Chord, and the title of a song from another album, In the Beginning, from On the Threshold of a Dream.

(Yes “album.” I’m old!)

Continue reading