Tag Archives: computer programming

Anyone Can Code?

14 Friday Sep 2018

Posted by in Opinion

≈ Leave a comment

Tags

, , , , , ,

There’s a general ethic these days — that anyone can code — and like a lot of things, there’s some truth to it, but also some silliness. As usual, it really depends on what we mean by “anyone can code.”

If we mean it in the same way we might say, “anyone can drive,” I think it’s silly. But if we mean in the same way we might say, “anyone can doctor (or lawyer),” well, then I still think it’s silly.

Continue reading →

The Software Industry

11 Saturday Aug 2018

Posted by in Opinion

≈ Leave a comment

Tags

, , , , , , ,

xkcd #2030 by Randall MonroeI cracked up when I saw this recent xkcd cartoon. Randall Munroe rarely fails to deliver, but this one especially caught my eye. It’s painfully on-point and quite dismaying on at least two points:

Firstly, that it should still be this bad given all the time, money, and attention, it has received is reason alone for dismay. Part of the problem here may be that we haven’t admitted how hard software is to get right.

But, secondly, software is central to our lives now — far more than airplanes, and even more likely than elevator rides. You might ride an elevator, at most, a dozen times a day, but software enters your life more times than that.

Especially if you use a mobile computing device!

Continue reading →

Knowing Where To Bang

02 Wednesday Aug 2017

Posted by in Stories

≈ Leave a comment

Tags

, , , , , ,

Sometimes ya gotta laugh. I just spent nearly an hour chasing one of those bugs that “can’t be happening” because “the code looks absolutely correct (as far as I can tell).” Of course, the bug, once you find it, was always hiding in plain view.

This time the fix involved adding just two characters, incidentally improving the program semantics, and very much reminded me of the old joke about the huge cargo ship that breaks down at sea…

Continue reading →

Iteration versus Recursion

19 Monday Dec 2016

Posted by in CS101

≈ Leave a comment

Tags

, , , , , , , , ,

When it comes to what makes a computer (or any other) language a programming language, there are three characteristics usually required:

  1. Saving state (variables)
  2. Selecting a code path (if-then)
  3. Iteration or recursion (or equivalent)

This post is just a brief note (for a friend) about the third item and why it allows three distinct options.

Continue reading →

State Engines, part 3

25 Wednesday Nov 2015

Posted by in CS101

≈ Leave a comment

Tags

, , , , , ,

In the first two parts of this series I’ve introduced state engines and taken apart a specific instance of an engine. Now it’s time to tie together the design idea with approaches to building a variety of such engines.

Because the programming logic is in the state table, the engine can be fairly generic. That means it’s possible to create a state engine framework you can reuse for a variety of applications.

Continue reading →

State Engines, part 2

11 Wednesday Nov 2015

Posted by in CS101

≈ Leave a comment

Tags

, , , , , ,

Last time I introduced state engines and state tables. I showed parts of a simple implementation of one in Python. It parsed the language introduced in Little Programming Languages. This post continues that, so be sure you’ve read that first article.

I got as far as the state table implementing the process, and that’s where this post picks up. I’ll also get into the SourceReader class that does the heavy lifting.

Continue reading →

State Engines, part 1

08 Sunday Nov 2015

Posted by in CS101

≈ Leave a comment

Tags

, , , , ,

At one point in my career, the state engine (SE) was one of my favorite AWK hammers. At the time much of the work involved text processing or, in some cases, serial byte processing (which is not quite the same thing). That sort of thing is right in the wheelhouse for a state engine.

They are a very useful tool and an important part of any programmer’s toolkit.

Continue reading →

Rule #4: Comment As You Go!

05 Monday Oct 2015

Posted by in CS101

≈ 6 Comments

Tags

, , , , ,

There is a common tendency, as we crank out code, to think that we’ll come back later and write some really good comments — comments that future reviewers will view with admiration for their clarity, completeness, and humor. But if we’re honest we have to admit: Later never comes. We never go back and write those great comments. Often we don’t write any comments at all other than some placeholder we might dash off at the time.

Which is why Rule #4: Comment As You Go!

Continue reading →

Getting to the Next Hill

23 Monday Jun 2014

Posted by in CS101

≈ 1 Comment

Tags

, , , , ,

Last week I took my car in for scheduled service, and when I asked how long it might take, the guy said it was specified as one-and-a-half hours of labor. He could do that because there are thousands upon thousands of data points where a competent mechanic has performed that exact service, so there is a very clear idea how long it takes.

But ask a researcher how long it will take to find what they’re looking for, and the answer is usually, “I have no idea. I’ll know after I find it.” The path a researcher follows is usually new and unexplored, so it’s impossible to predict how long the path actually is.

Creating new software is much more like research than auto service, because it involves traveling unknown ground. Despite this, software development managers often act as if new development is predictable.

It often isn’t!

Continue reading →