Monthly Archives: August 2011

August 27, 2011

Theories About Swans

I’ve written articles here that touched on art theory, quantum theory, science fiction theory and number theory. There are many more theories: gravitational, electromagnetic, economic, social. Of course, there is also pure, practical and applied theory. The idea gets around. On the outskirts there are theories about UFOs, ghosts, Noah’s Ark, many more!

And there are the my theory theories put forth from soap boxes, fliers and now blogs such as this. Literally such as this, since here’s my theory about theories.

A theory, generally speaking, is a kind of statement about some aspect of reality, existence, life. A theory is proven or unproven. If it’s proven, it’s either proven true or proven false. While it is unproven, the matter of whether the statement is true or false remains open. Theories almost always start unproven; some later graduate to proven status.

The goal of any theory is to be proven. In the abstract, it doesn’t matter if a theory is proven true or proven false. (It may matter if you were hoping for a particular outcome!) Once proven, a theory is a foundation on which to build new thoughts, new theories. In fact, proving a theory false can be a good result because it closes all paths leading from that theory. This frees you to explore other areas, which is good; there are so many areas to explore!

It turns out that theories can be hard—or impossible—to prove one way, but much easier to prove the other way. (Which way is true and which is false depends on the theory.) One easy way to prove a theory involves finding an exception to the theory’s statement(s). This leads to the idea of a falsifiable theory; that is, a theory should be something we can try to break. If we can break it, the theory is false. The longer it survives our efforts to break it, the more likely it is the theory is true.

To understand why it works this way we can think about swans…

There’s no such thing as a black swan

Consider two parallel theories. One says that there are no black swans; the other that all swans are white. The two theories are similar in that both make statements about the colors of swans. But the first says there is no such thing as a certain type; the second says they’re all a certain type.

(It is probably easier to imagine proving a much smaller theory: there are no black swans in my yard right now; or if you prefer, all swans in my yard right now are white. Note that although neither theory requires any swans in your yard at all, the second one seems to imply them. More importantly, notice that small theories don’t necessarily translate into big theories. The fact that there are no honest politicians in your yard right now doesn’t necessarily mean they don’t exist at all. More to the point, if there are swans in your yard, theories about their color may not be the best focal point for you right now.)

We can prove the first theory (no black swans) two ways: we can examine every swan that ever was, is now, or ever will be. If we can do that (we can’t, but if in “theory” we somehow could) and find none that are black, then the theory is finally proven true. But if we find a single black one along the way, we stop; the theory is proven false!

The very important point is that proving it false lets us stop testing. It also elevates the theory to a proven status, but—and this is the crucial part—it lets us stop testing. Of course, so would proving it true…

But proving the theory true requires searching all possible swans, and that’s not possible. Generally speaking, a no such thing as theory is, impossible to prove true. It’s impossible to prove that there’s absolutely, 100%, no such thing as UFOs, ghosts, God(s) or flying spaghetti monsters. The only way to prove there’s no monsters under the bed is to check under the bed. Every bed. In all of time and space.

Now consider the second theory (all swans are white). As before, to prove the theory correct we need to examine all possible swans. Again, each swan must confirm to our theory—it must be white—or the theory is proved false (and we stop). But so long as each swan we find is white, the theory is open, and we must continue with the swan search.

A difference is that the second theory (swans all white) is a statement that all swans have a specific trait (color=white). Any color variation makes the theory false. The first theory (no black swans) is a statement that all swans lack a specific trait (color=black). Color variation doesn’t matter so long as it doesn’t vary to the color black. Assuming different swan colors, the second theory should be easier to prove false, because any variation of the trait makes it false.

That is why all X are Y theories tend to end up proving false. The all swans are white theory is as easy to prove false as the all Bruce Willis movies are good theory. Or just about any other theory making universal claims about a group of whatevers. And such theories tend to be ugly when applied to groups of humans—plus they tend to be false—so they are doubly wrong.

Note that the assumption a trait is distributed isn’t always warranted. This is why swans are a canonical theory metaphor. A theory that all swans are white is sensible, because most swans are, in fact, white. And since most swans are white, or at least more white than not, it’s easy to guess that there are no black ones. Swan color, we can imagine, is not distributed. Swan are white; swan are not black.

In any event, proving either theory false—which we can do if we find the right sort of swan—graduates the theory to proven (proven false). We can do this because the theories makes statements we can test and possibly prove false. Both theories are falsifiable.

Reverse Theories

The natural question is, does it work in reverse? Are there theories that are easy to prove true but impossible to prove false? In fact, there are, but in some cases all we end up with is different wording. We’re still breaking the theory by finding an exception to what it says.

Consider the theory some swans are black. This is precisely the reverse of the original black swan version. In this case, finding a black swan makes the theory true (not false, as in the original) and lets us stop. And we must check all swans in creation (and find no black ones) to make the theory false.

A reverse version of the second theory is some swans are not white. Again, the true/false outcomes are reversed. Again, one outcome lets us stop the proof process, the other requires (literally) forever.

Both these theories use some with regard to swans. If a swan qualifies as some swans, then these are precise mirrors of the original theories. But a theory can also involve a group. The theory there are at least 100 black swans, for example. The question is whether a theory about some things is useful. It’s the theories about all things tell us important things about reality.

Getting Formal

For those interested in the technical details, our two theories have formal logical expressions; they can be stated mathematically. Let’s first state the theories a little more formally and then a lot more formally:

For all swans, no single swan is black.

For all swans, each single swan is white.

The formal logic (mathematical!) versions go like this:

∀ s ∈ Swans: ~black(s)

∀ s ∈ Swans: white(s)

The little s stands for a swan; the upside-down ∀ means all (∀ll); the ∈ symbol means is a member (element) of (∈lement); the tilde (~) means not.

So the first one reads as “for any swan in the class of all Swans, that swan is not black.” The second one reads as “for any swan in…all Swans, that swan is white.” In both cases, the theory asserts the formula is true. If we find a case (a swan) that makes the formula false, the theory is falsified.

Keep in mind that black swans and white swans are just a metaphor with no connection to actual blackness, whiteness or swanness. It was all theoretical theory anyway.

2 Comments | tags: logic, no black swans | posted in Basics, Philosophy

August 27, 2011

Sideband #41: CS Jokes

By Wyrd Smythe

I close the first round of CS101 articles with some of my very favorite CS jokes. Sure, they’re esoteric, but they’re also really funny. Thing is, you may have to trust me on that.

Binary

I have a sign in my cube:

There are 10 types of people…

Those who can count in binary,

and those who can’t!

It garners two reactions. Some people just walk away puzzled. Some people look puzzled for just a moment and then they crack up.

3 Comments | tags: binary, COBOL, computer programming, humor, jokes, Unix | posted in Computers, Sideband

August 26, 2011

CS101: Four Principles

By Wyrd Smythe

If nothing else (and I think there is plenty of else), I can look back on all those years of writing code and pick out the main themes and principles, the things that seemed to matter most. That’s what this CS101 series is about: things I think matter most when it comes to designing software.

Lately I’ve been looking into fours, doing things in fours. With that in mind, here’s Four Primary Principles for Programmer:

Learn to learn.
Learn to look stuff up.
Learn to communicate.
Learn your craft.

That’s right; learning your craft is number four! I think the first three are good principles in general. All three are useful skills in life, but I’ve found them to apply particularly to software design. I’m not saying software is unique in this; many professions need constant access to stored knowledge. No one knows all the details, so everyone needs documentation at some point!

Knowing your craft is certainly important—it made it into the top four! But the first two are constant job requirements, and the third is an invaluable skill. All three apply regardless of your craft. Let me explain them in more detail.

Learn to learn. This is a required skill. Programmers constantly learn new things. There are new tools, new languages, new processes, new standards, new client contexts and new technology. This is an evolving field; there’s always something new. I’ve learned as much in this past year as in every one of the 30+ past years I’ve been doing this.

In fact, I advocate teaching yourself one new computer language a year. I don’t make the recommendation to exercise your learning skills, although it does do that. I think learning new programming languages is important to your understanding of what they are and how they work.

It’s like a musician learning many instruments. If it’s about the music, then the tools—the instruments, the programming languages—don’t matter. Which is not to say that becoming a virtuoso on an instrument isn’t a valid choice. But the job pool is limited, so you need to be a true virtuoso.

Each year, just pick a new language and learn it (the interweb makes that very easy). You have plenty to choose from: Python, Ruby, Scheme, Haskell, Smalltalk, Lisp, Erlang, Prolog, APL, Forth, Eiffel, Perl, Ada,… The list continues, and those are just a few of the slightly to somewhat off-the-mainstream languages! You might be amazed at how many programming languages there actually are.

Learn to look stuff up. Another required (and acquired) skill. No one can know it all, so the key is knowing where to look stuff up. As I said, we all need the documentation sometimes. That was Scotty’s secret, you know. He had access to Wikipedia!

Seriously, Wikipedia is wonderful for technical research. The quality of Wiki entries is high on technical material (probably because of the many technical people involved in Wiki and in the interweb). And technical material doesn’t have the political freight as does some social material. Genuine error is rare, let alone deliberate disinformation.

The interweb in general was always rich in technical resource. Its origins were technical, so for a long time its content was also heavily technical. But recent searches turn up results with a lot of (a) people already asking your question and (b) people guessing at the answer for group (a). It has become harder to sift out the actual answer.

But it’s usually still there. The interweb remains a great, if noisy, technical resource!

Learn to communicate. This covers tools, such as Word and Excel (or whatever), but also has to do with improving your writing, and possibly speaking, skills. You may need to do documentation for others, or give a presentation, but you’ll find that skill with documentation and analysis tools is also a benefit to you.

This occurs in two ways. First, you can use these tools to explore a problem or at least put it down on paper. Sometimes a diagram or a flowchart or some kind of drawing is very helpful in breaking down and understanding a problem. Second, documenting your work using modern tools for the job is almost pleasant; the result definitely is!

You will want to be familiar with a good authoring tool (such as Word), a good data analysis tool (such as Excel), a good drawing tool (programmers make many diagrams), and maybe a presentation tool (PowerPoint; sorry about all the MS Office references, but they are very good tools) and a database tool (guess what: MS Access).

The world is increasingly electronic, and it is more and more common to communicate by electronic means. You’ll want to be facile (which includes being literate and clear) with email as well as with whatever other tools make sense in your business. Increasingly, communication means the interweb, so you’ll want to be interweb aware if not savvy.

Interesting how the interweb manages to be a part of all three first general principles. Think it’s invaded and permeated our life much?

Learn your craft. Well, duh. Naturally you want to be good at what you do. That includes the background knowledge, such as knowing the programming language, as well as specific knowledge, such as the data scheme of your database. The stronger your background knowledge, the more you can see of a system, the more of that system you understand. The more you can see, the better you are at debugging or making changes.

Background knowledge also tends to transfer from position to position better than specific knowledge. XML, for instance, is used in so many areas of the computer world now that knowing it is a big benefit. Knowing how computers work and communicate on a general level can be extremely helpful in giving you utility in many areas. It gives you a strong foundation on which to build.

Knowing a given language, such as Java, is fairly useful, but can narrow down the field some. And consider that a C programmer, or a C++ programmer, might well have felt like a Java Programmer does today. This, by the way, is why you want to learn new languages! It looks like Java is here to stay, it looks like there are plenty of Java jobs, but eventually the next new thing does come along. Background knowledge (and the ability to learn!) helps with the next new thing.

There’s a lot more to it, of course. Programmers need attention to detail, for example. When it comes to software, you do have to sweat the small stuff. Each bit matters!

Leave a comment | tags: computer programming, programming, software, software design, writing software | posted in Basics, Computers

August 25, 2011

CS101: Always Use LT

By Wyrd Smythe

Here’s a simple tip! I can’t begin to count how many potential code bugs this has eliminated. It takes some getting used to but once you make it automatic it’s a real help in keeping code and your thinking correct. The tip is this: when you write relational expressions, always use less-than, never use greater-than.

Tip: Always write (B < A), not (A > B).

Make Less Not More

Always write your relational expressions to use less-than and so that a true evaluation puts the lesser quantities on the left of the greater quantities. In rare cases a language doesn’t allow the appropriate syntax, but in most cases you can write the less-than version of any expression. This is especially important when testing a value range (for example, between ‘A’ and ‘Z’).

By the way, I admit to assuming the Euro-American left-to-right bias here. In cultures with strong right-to-left orientation, I hope my logic works in mirror reverse. The point is to use instinctive mathematical less-to-greater orientation in relational expressions to help avoid logic errors.

The intent is to apply the left-to-right orientation of the number line to relational expressions. On the (Euro-American) number line, values run from lesser on the left to greater on the right. If you pick a number, L, from the line and pick another number, R, to the right of it, the relation (L < R) is always true and (L > R) is always false.

If the expression logic follows number-line logic, the expression logic makes more sense. For example, if we want to test that x is in the [A–Z] range, one way to write the expression is:

(‘A’ <= x) AND (x <= ‘Z’)

The test value, x, visually falls between the ‘A’ and the ‘Z’. In this form, the expression resembles a common mathematical form:

(‘A’ <= x <= ‘Z’).

Most computer languages do not allow the above syntax, but nearly all allow the first one, which comes very close. Compare this to a common alternative, that places the variable first:

(x >= ‘A’) AND (x <= ‘Z’)

In a complex expression, following mathematical number-line logic can make an expression more clear and help highlight logical errors. For example, consider this (which is not at all untypical code):

((‘A’ <= x) AND (x <= ‘Z’)) OR ((‘a’ <= x) AND (x <= ‘z’)) OR

((‘0’ <= x) AND (x <= ‘9’))

And compare it to this:

((x >= ‘A’) AND (x <= ‘Z’)) OR ((x <= ‘a’) AND (x <= ‘z’)) OR

((x >= ‘0’) AND (x <= ‘9’))

I think it’s much easier to use the first one! In fact, did you spot the error in the second version? The first version is much easier to debug, because you know all the arrows point to the left.

Note that this follows the standard looping conventions:

{J=0; J < N; next J}

{J=1; J <= N; next J}

It takes a while to train yourself to use less-than strictly, but once you do, your coding skills will be stronger. You may even find yourself going back and “correcting” old code. It will start to look “wrong” to you!

Leave a comment | tags: computer programming, software, software design, writing software | posted in Computers

August 24, 2011

CS101: Clarity Trumps Everything

By Wyrd Smythe

Clarity is the #1 priority when writing code. Clarity trumps everything else; it’s even more important than the code being correct! One of the biggest wins a serious programmer can offer is writing clear, readable code.

Source code is for the human reader; it’s not written like that for the computer. If it were up to the computer, humans would use the same ones and zeros it does. It would be much more efficient that way. But us (inefficient) humans need ways to write and talk about computer programs. We use many invented languages, computer languages, to do that. And when we write in these languages, it is crucial to be clear.

Clarity is more important than correctness (which is still very important!), because clear code can be fixed if it’s incorrect. Unclear code is harder to work with. It’s harder to find, let alone fix, bugs. Clear code also helps debug as you write; you are more likely to catch your own errors when you write clear code.

Clarity is more important than comments (which are still very important!), because clear code is readable! Part of clarity is using good object names, and that helps the code be self-documenting. On the other hand, writing clear code means writing good comments, so don’t skip commenting just because you think you write very clear code.

To be honest, writing good comments is such a close second, it’s hard not to argue it’s tied for first as being a #1 priority when writing code. It’s a wash as to which mess I’d rather not clean up: clear code with no comments; code with good comments but no clarity. I think it would be easier to add my own comments to the clear code than to clear up the commented code.

Clarity is important, because it enables change. Clear code has a longer life. Unclear code can be difficult (or impossible) to maintain. I have sometimes found it easier to throw code away and start fresh, than to try to work with “a big ball of mud.” Clear code is maintainable and reusable.

The Lesson for Today

Always think about the next programmer who has to read and understand your code. That programmer is quite possibly you in six months when you have to revisit your code. Except now you’ve forgotten it all and it looks as new to you as to anyone else! Writing clear code benefits you when you revisit it as well as when you write it.

Write code that a human being can read. (Assume a human being that is a programmer who knows the language. You don’t have to write code for novices.)

Write a Formal Letter

Think of writing code as you think of writing a formal letter.

When you write a formal letter, you have two goals: you have a message to communicate, and you must follow the protocol of a formal letter. Your message comes through when your writing is clear and good. Following the protocol is a matter of knowing and following some syntax rules.

A message + formal syntax. The result is a document with a context.

Code is the same way. It has a specific message to communicate, and there is a formal syntax the writing must follow.

Following the syntax of the programming language is just one part of the formality of writing code. In a formal letter, every part has meaning. In some contexts (international diplomacy, for example), every sentence, every punctuation mark has meaning. Even the spacing between parts can mean something in some contexts.

So when you write code, think of it as a message you wish to communicate and make your code look clean and readable.

Literate Programming

Literate Programming is a specialized approach to writing code that enables a programmer to write at a more human logical level, somewhat like a story. The source code was designed to be very readable by humans, and literate programming tools could translate the source into both code for the computer and documentation. It’s a huge win when you have the language, tools and practice to use it.

In the meantime we can borrow from the idea of source code as a book that can be read sensibly. A source code file should unfold from top to bottom like a story with a beginning, a middle and an end. The idea is to give the reader a good understanding of the function and purpose as they read.

For example, in Java this applies to how your write your class and interface files. Where do you put the constructors? Where do you put the static and instance properties? Where do you put static properties and methods versus the non-static? Where do you put the get and set methods? Is there a specific place for standard methods such as toString, equals, compareTo and hashCode?

The real point is this: the order of things in a code file is important. The order communicates information. If there is no structure in your source code, if the order of things has no meaning, then you lose the chance to communicate to the reader. You lose the chance to give yourself a known environment! Skilled programmers use the ideas behind literate programming and structure their source code to communicate more richly.

This means that once you know a programmer’s structure, you can navigate their code better. You know where things are. You know what they are likely to be named. When code has structure and order, it has a familiar shape.

Clarity, Clarity, Clarity

The order of things is one way you make source code clear. I’ve also mentioned the importance of good comments. (I’ll talk about good comments vs bad comments another time.) There are other important ways you write clear code.

The names of your variables go a long way in communicating your intent. The compiler couldn’t care less, but a longer, descriptive name can be a blessing for a human reader. Don’t be afraid to use descriptive variables names. The days of compiler length restrictions are safely behind us, and editing environments help remember and type names for us. Besides, programmers should be good typists, right?

At the same time, don’t go nuts. Verbosely long names can make the code look cluttered and ungainly. You want some degree of streamlining; that’s a part of clarity, too.

The thing about variable names is that you want a naming convention. You want a way of going about the business of variable names that gives you the same name in the same situation. I’ll talk more about that another time, but one example is that my loop indexes are always ix. The i changes to other letters, but the two-letter name ending in x is a standard I use faithfully.

After years of doing this, I sometimes surprise myself by how well variable names match across a project. Sometimes on a large project I’ll start to create a new class and then realize something like it already exists in the project or in a library. If it’s one I made in the last few years, chances are the one I just started looks surprisingly the same. Source code is one place where you want to be predictable. You want some moves to be instinctive.

A more subtle form of clarity, one that takes experience, has to do with the form of the code. The way the code goes about its business can be opaque or transparent. Source code should be as transparent in its intention as possible. Source code should speak its mind about what it’s doing. There isn’t space here to go into that, but I’m sure I’ll return to the topic often down the road.

Let me end with an example of a very simple form of clarity. It has to do with lining things up in your source code. Compare the two variable lists below:

    protected Logger myLog;
    protected HashMap<String,String> myMappedFields;
    protected HashMap<String,QueryChild> myChildEntityTypes;
    protected String myInstanceId;
    protected WebServiceRequest myRequest;
    protected SAXOnDemandMapping myFieldMap;
    protected SAXOnDemandEntity myCurrentEntity;

Just aligning the names makes the code easier to read:

    protected Logger                       myLog;
    protected HashMap<String,String>       myMappedFields;
    protected HashMap<String,QueryChild>   myChildEntityTypes;
    protected String                       myInstanceId;
    protected WebServiceRequest            myRequest;
    protected SAXOnDemandMapping           myFieldMap;
    protected SAXOnDemandEntity            myCurrentEntity;

It all boils down to the first rule:

Always write source code to be read!

Leave a comment | tags: clarity, computer programming, programming, software, writing software | posted in Basics, Computers

August 23, 2011

CS101: Easy to Hard

By Wyrd Smythe

It’s been said that programming is an exercise in managing complexity, and while that’s true, it’s only part of the picture. (Still, it’s a pretty big part!) More to the point, managing complexity applies to much more than software design. A defining characteristic of modern life is its complexity, so learning to manage it might be a Pretty Good Idea!

Thinking about a friend struggling with the complexity of life lead to remembering of one of P.J. Plauger‘s articles about problem modeling from his book, Programming On Purpose. (The book is a collection of his essays from the long-defunct, but most excellent, Computer Language magazine.)

Thinking about Plauger’s ideas again lead to thinking they might be worth sharing. Whether fresh or review, these ideas capture six key basic analytical techniques nicely. If you’ve never really thought about them before, you may find the ideas useful.

Leave a comment | tags: bottom-up, computer programming, easy-to-hard, programming, top-down | posted in Basics, Computers, Philosophy

August 22, 2011

Computer Programming Ducks

By Wyrd Smythe

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.

So 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 jelly beans. It’s all the exact same thing. What matters is the pattern of thing and not thing.

So 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 use 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; sales people 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 blue prints.]

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.

Leave a comment | tags: abstraction, computer programming, programming, software, software design | posted in Basics, Computers

August 21, 2011

Sideband #40: Chessboard of Rice

By Wyrd Smythe

I recently mentioned a parable about grains of rice and a chessboard. If you were industrious enough to try your own interweb search for [parable 64 squares grains] you might be ahead of me. Or you may have known the parable already. For the rest of you, here’s the deal.

Stripped of the narrative, it’s about taking a chessboard and placing a single grain of rice in the first square (in some versions, it’s a grain of wheat). In the second square, place two grains of rice—double the amount in the first square. In the third square use double the grains of the second square. For each square on the chessboard, use twice as many grains of rice as used for the previous square.

I’ll come back to the punchline, but I stripped the narrative. Let me fix that.

Leave a comment | tags: exabyte | posted in Math, Sideband

August 20, 2011

Sideband #39: “Star Trekking It”

By Wyrd Smythe

As a quick Sideband sidebar to the Star Trek holodeck article just published, I want to mention a metaphor I use to refer to a common science fiction fan phenomenon. The metaphor has a label: “Star Trekking it.”

A while back I mentioned another metaphor: “doing a Boston.” This is like that. It’s a specific reference applied to a general situation. In this case, the metaphor is a general idea in a specific context: explaining away ridiculous stuff in Star Trek.

And make no mistake, Star Trek needs plenty of explaining!

Leave a comment | tags: Captain Kirk, Captain Picard, Star Trek, transporters, warp drive | posted in Basics, Sci-Fi Saturday, Sideband, TV

August 20, 2011

Why I Hated The Holodeck

By Wyrd Smythe

This is a rant about an aspect of Star Trek that always bugged me: the deadly, dangerous, ridiculous Holodeck!

If it seems familiar, you may have encountered it before. I wrote it back when the show (Star Trek: The Next Generation) was still running (1987-1994) and published versions of it then and later in various online venues (FidoNet, USENET, some websites). Long-time friends will certainly recognize the rant if not the writing.

If you were on the net before the web, and you hung out in Star Trek places, you might have stumbled over this.

32 Comments | tags: Captain Picard, Enterprise NCC-1701-D, holodeck, sci fi, science fiction, Star Trek, TNG | posted in Rant, Sci-Fi Saturday, TV, Writing