Psalm 150:6 – David’s Last Scripture

Let every thing that hath breath praise the LORD. Praise ye the LORD.
Psalm 150:6

King David had much to say on the subject of the Lord, as the known author of over half of the book of Psalms. The Lord had some important things to say about David. He was described by the Lord as “a man after mine own heart” (Acts 13:22), so it seems clear that David had either an acute understanding of, or a natural affinity with the Lord. Understanding this, when David speaks of the Lord, we would do well to listen carefully.

Our verse here is the final psalm and thus the last recorded verse of scripture brought to us by David. While the entire body of scripture by or about David is interesting, there is always something extra interesting about final words. It seems reasonable to expect the final scripture of David to be an important observation about God and I believe that David comes through for us powerfully here.

Like many biblical final words, David’s were words of encouragement. Encouragement to praise and worship the Lord. Perhaps this is surprising to some. After all, David wrote often of the attributes of the Lord. He wrote about his love and his mercy and his protection. He wrote about his majesty and even prophesied of his crucifixion. These are all weighty matters that would have been worthy of being David’s final words. Instead, David reverts to type and his worshippers heart rises up and he tells us that the most important thing we can do is praise the Lord.

David leaves no wriggle-room for those looking to avoid this responsibility. He qualifies his directive by including all who have breath. That’s a solidly inclusive call to action. If you’re breathing, you should be praising the Lord. Because, according to David, that’s the most important thing for us to do. And a great way to round out the book whose name, in Hebrew, means “praises”.

Chappell’s Fifth Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

After quarter of a century of tinkering with computers and 15 years of programming them to earn my living, I would have to say that some observations are so obvious that I almost feel it’s redundant to speak them. This law would certainly fall within that realm. But, repeated observation of real life in the I.S. industry, on both sides of the Atlantic, has given me cause to believe it necessary to share it.

Simple is good.

As a rule of thumb, when considering designs or development approaches, always err on the side of simplicity whenever possible. Naturally, there are a few things in this life that are blisteringly complicated, but unless you really are a rocket scientist, it’s unlikely that what you do is one of them.

I have seen far too many designs ruined for the lack of simplicity. I have witnessed far too much code that spends more time trying to be clever rather than getting the job done. This law pretty much goes hand in hand with my second law of programming. In order to write code that you can read at 2 a.m. you need to write in a straight-forward fashion. To be able to write straight-forward code, you need a simple design. You need a design that solves the problem at hand and doesn’t play the “how many patterns can I squeeze in one UML diagram” game.

Simplicity also has the added benefit of producing systems that work better and are ready sooner. Simpler systems have less components, less relationships between the components to manage and a much lower chance of adverse behaviour between components. If programmers produced physical items, we’d describe them as streamlined and with less moving parts!

Learning Projects

When learning a new programming language, and I’ve done this more than once, there are certain steps that I typically take in the process. I like to poke around the language web site and then read the getting started tutorials. If I like what I see and it fits my definition of an esoteric programming language, I’ll install it and try my hand at some examples from the tutorials and the classic hello, world program.

These steps seem to be fairly normal for geeks like me and certainly the writing of a hello, world program is enshrined in programming lore and tradition. What is less clear is the recommended path to take after that. Some people complete tutorials, others buy books and work through them and then some dive in and work on a project so they can learn as they go. None of these are bad approaches, but I think that there needs to be something between working through tutorials or books and the big project for learning.

To this end, may I suggest the concept of Learning Projects? This involves writing a series of programs of increasing complexity that incrementally explore the capabilities of the language. I’m looking at replicating a select number of the traditional Unix tools, starting with the simpler ones and expanding from there.

In some ways this is an expanded view of the concept of Learning Tests. Learning tests are tests written by a programmer learning a specific language to help them understand the language they are learning. (I don’t know who first coined the term, but I first heard it from Mike Clark.) There is nothing wrong with learning tests, but when approaching a wide number of languages, not all will have testing frameworks available and, most importantly in my view, the end result is not anything you can use or recycle components of after the learning effort.

Each of the programs in the Learning Projects are sequenced so that the programmer is learning at least one new capability of the language. These capabilities include writing to the standard output, return values, file handling, calculations, directory operations and system calls.

Now, allow me to present my suggested list of Learning Projects:

  • Hello World – This ensures that you can compile and run a program in the language and get standard output somewhere that you can find it.
  • true & false – Ensures that you can pass return values to the operating system.
  • echo – Requires you to process command-line arguments.
  • cat – Requires you to be able to read files and standard input.
  • wc – This requires handling multiple files, loops and arithmetic.
  • touch – Requires you to be able to create a file or update its timestamp.
  • cp – Ensures that you can read from and then write to files.
  • head & tail – Shows the ability to selectively read lines from files.
  • grep – Apply regular expressions to file contents.
  • strings – Shows the ability to selective read bytes from files.
  • od – Read from a file and apply fancy output formatting.
  • rm & rmdir – Be able to delete files and apply recursive deletion.
  • find – Recursive directory descent.

I believe that by the time a programmer has worked their way through this list of Learning Projects, they will be ready and well prepared to take on an interesting project for the purpose of more fully learning their programming language of choice.

Chappell’s Fourth Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

Software quality, that marvelous thing that every programmer seeks for, as I explain in my third law of programming is all about caring. The only problem is that while “quality is caring”, there have to be actions that this caring drives you to. The first and most important of these actions is unit testing.

Unit testing is the first tollbooth on the road to software quality.

I like to describe unit testing as a toll booth because there is a price to pay for quality. This price is typically non-monetary, but nevertheless very real. The analogy of a road seems to fit software quality very well. Software quality is not a one time thing, it is a journey to a destination. The toll booths on the road to software quality are the price that we must pay, the efforts that we must make, to complete that journey.

Journeys have three phases, the beginning, the travelling and the arriving. Unit testing is the beginning, the price of admission, that first tollbooth which permits you to drive on the road. With toll roads there is no free travel. You pay the toll to get on the road, you pay regularly as you travel along the road and then you pay again to exit the road.

There is no free lunch, or TANSTAAFL as the Perl guys like to say. If you want to do anything well, it’s going to cost you time, effort, money or all three. Software quality follows this fundamental law of life.

Chappell’s Third Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

During a conversation the other day with a friend of mine (name withheld to protect the innocent) the subject of software quality came up. My friend was very concerned that raising software quality would be an expensive endeavor. They were quite surprised when I told them that quality does not have to be expensive and that it can be close to free.

“How is this?” you ask. Simple, the truth is that:

Quality is caring.

Software quality is like security, you have to build it in from the initial design. Retrofitting is not an option. The way that you build quality into a system is by caring from day one.

When you care, you consider matters more deeply. Your requirements gathering will be a little more careful. Your system design will be a little more thought through and better researched. Your code will be cleaner. Your testing will be more consistent. Your release process will be followed closely. Everything will be better.

There are some things that you cannot measure objectively and there are many aspects of quality that are subjective. This does not mean that they aren’t important and it certainly does not mean that your customers won’t notice. Quality is something that shines through and is visible, even when it’s not measurable. Delivering a quality system shows that you care, because quality is caring.

Chappell’s Second Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

With all of the benefits of modern computer science research, I find that many programmers still omit one basic thing from their programs. No, I’m not talking about patterns, or POJO’s or any of the other trendy buzzwords that a modern programmer is expected to be knowledgeable of, rather I’m talking about something more basic than that.

I’m talking here about the ability to:

Write code that you can read at 2 a.m.

As any programmer that has taken a support call in the middle of the night will tell you, supporting other people’s code is the worst. At least with your own programs you know why you wrote them and what they’re supposed to be doing, but with someone else’s, you usually don’t have that luxury.

This will usually result in frantically looking at any available code for the program to see if it offers any clues about it’s purpose for existence. Naturally, this is where you discover that the author had the bizarre habit of using single letter variable names for everything and you can’t understand a thing. And not a comment in sight, of course.

The answer, of course, is to assume that someone might need to understand your code in a hurry and that you should write it clearly and concisely, so that it can be read even at 2 a.m. by someone in a frantic hurry, that is still trying to rub all the sleep out of their eyes and who is unlikely to have a copy of the specification around to read.

Chappell’s First Law of Programming

(One from the archives. I wrote this ten years ago. I think it still stands.)

There have been many fine developments in the art of computer programming in the last few years. I especially appreciate “Test Driven Development” (I consider myself fully test-infected) and automated build processes using tools like ant or Maven. And there is still more to come, be it Aspects, grid computing, or lightweight web frameworks like Struts. This is all very good and I welcome it.

But there does not appear to be any great appreciation of, what is one of the fundamental “laws” of computer programming:

Working code trumps everything.

This is a basic truth, at the same level as “1 AND 1 = 1″. Learn it, live it, there will be a test.

As a computer programmer (24 years under the belt, 14 with salary), I love to write code and I love to re-write old junky code, but I have learned that there is enough work to go around, without the gratuitous re-writing of old code. If it works, and usually it does, if we can be honest with ourselves, then we should leave it well enough alone.

I realise that this is close to the old adage about “don’t fix what isn’t broken”, yet I feel that it’s sufficiently different to deserve specifying individually. I’m not saying that we should ignore bad or faulty code, just because it mostly works. Any measurable error rate in code means that it doesn’t work to my satisfaction. I’m talking mostly about legacy code, typically written in COBOL and running on a mainframe. We younger bucks (less than 28 hex thank you) tend to look at older systems and insist that they should be re-written in <insert name of trendy programming language here>. This is the time to remember that working code trumps everything. I don’t care how buzzword compliant your latest language is, if I have working, proven code running, then I say leave it alone and figure out new and interesting ways to interface to it if you have to or just get on with writing some of the boatload of other systems that people are asking us for.

Diary Of A Great Week

The past week has been fun and satisfying. There were a few challenges, but the end result was good, so let’s celebrate by recapping the good things with a selection of photographs.

Watching the Madison fireworks

Watching the Madison fireworks

A beautiful rainbow seen from our front porch

A beautiful rainbow seen from our front porch

Peter's first visit to the Shawano Perkins

Peter’s first visit to the Shawano Perkins

Part of the Princess Posse at Family Camp

Part of the Princess Posse at Family Camp

The view across the lake at Shawano

The view across the lake at Shawano

With my lovely bride by Shawano Lake

With my lovely bride by Shawano Lake

We stopped for Ice-cream while traveling around Shawano Lake

We stopped for Ice-cream while travelling around Shawano Lake

Peter riding a pig

Peter riding a pig

More of the Princess Posse

More of the Princess Posse

Peter enjoying a deep theological discussion with my pastor

Peter enjoying a deep theological discussion with my pastor

Visiting with extended family on the 4th of July

Visiting with extended family on the 4th of July

Sorry for the poor photo quality. I need to take my big camera with me more often, but even mobile phone pictures are better than no pictures, so please forgive me.

What Is An Esoteric Programming Language?

Perhaps you don’t ask yourself such questions, but I find myself pondering the nature of esoteric programming languages. I wonder what makes a programming language esoteric. I wonder whether there is a benchmark by which we can know such a thing. Does a mention on Lambda-The-Ultimate secure the status of esoteric? How many users can an esoteric programming language have before it is no longer esoteric? How many books can be written about it before it takes on the veneer of being mainstream? I don’t think anyone knows. I certainly don’t know. I need to arrive at a definition of esoteric programming languages.

How does one begin deriving a definition for such things? Perhaps I could start by saying that esoteric programming languages are those which are not mainstream? That sounds nice, but then, at the top end, how do I define mainstream and at the bottom end, how do I differentiate between experimental programming languages and esoteric programming languages? A tricky conundrum.

At the bottom end of the scale, how many users does an experimental programming language need to graduate to esoteric? On the other hand, does it get any more esoteric than a programming language with exactly one user and that being the language designer and implementor? I suspect not.

For mainstream languages, how do we determine the transition point? When does an esoteric programming language become mainstream? Does the number of users or downloads count? Does making it onto the TIOBE top twenty most popular languages list prompt the change? Is it all a huge conspiracy by the few remaining print publications of what used to be known as the computer press? These questions are hard to answer.

Yet, still I feel that I need a definition of an esoteric programming language. Not that anyone else will use it, but I need one that satisfies my view on these things. I suppose that a definition just for me is allowed to be qualitative rather than quantitative. It’s my definition and I’m going to live with it, so it would be helpful if I liked it. As I do not know exactly what one is, although I know one when I see it, I must be imprecise and apply a number of vague criteria. To that end, here are my criteria:

It must be hard to get a business programming position for the language in the mid-west of the United States. We are very conservative here in the mid-west, so if anywhere would let you write code in it, it must be mainstream. (The universities are more adventurous, hence the distinction of business programming.)

It must be Turing complete. SQL need not apply.

It must be 100% FOSS (Free or Open Source Software). If a company owns it, then after deciding to allow you to use it, they would be under no obligation to continue to allow you to use it. The new Swift language from Apple is an example of a language that fails this criteria. Java also fails here because while the JVM is open-sourced, the Test Kit is not and Oracle (the new owners) have been quite robust in asserting that they still own the copyright on the Java library API.

It must be available for more than one operating system. If I write a program in your language, I want to take it with me if I change platform. F# from Microsoft fails this criteria because while I am assured that it has a number of fine qualities, it only runs on Microsoft Windows.

It must have a decent library. If anything separates the experimental programming languages from the esoteric ones, then this may well be it. Java, when first introduced, set the bar for minimum library quality. Few languages these days come close to that level of initial standard library, but there must be enough available for me to write non-trivial programs that get basic tasks done.

It must have some documentation, an official tutorial and an official web site. Your documentation doesn’t have to be written and typeset by Donald E. Knuth himself, but it should be understandable enough that I can try using it to write a program or two.

It should be fun to work in. This is obviously the most subjective criteria, but if I’m not being paid to program in your language, you at least owe me an effort to make it enjoyable.

And it would be really helpful if it could handle Unicode. In the core language would be best, but through a library would be acceptable.


Faith is interesting. It is many layered, with great depth to it if you care to spend enough time thinking about it. Some mix it up with grace or belief and consider them all of a similar thing. And while that may be close enough for teaching Sunday School children, it has its own distinct nature that rewards further investigation.

A definition would be useful at this point. If we are to speak of something, then knowing whereof we speak is always appropriate. Definitions of faith abound. Webster’s Dictionary is always a good place to start, so let’s see what they say:

Faith: allegiance to duty or a person; loyalty … belief and trust in and loyalty to God … something that is believed especially with a strong conviction.

For reasons that you’ll see in a moment, allow me to also include the definition of “belief”:

Belief: A state or habit of mind in which trust of confidence is placed in some person or thing.

That’s good, but it doesn’t seem to perfectly capture the understanding of faith that years of living it brings. Time to turn to the Greek language and see what we find when we look at faith there. The Greek words most often associated with “faith” are pisteuo and pistisPisteuo is usually translated as “believe”, while the noun form pistis is normally translated as “faith”.

pisteuo (Amplified Bible): To adhere to, trust, to have faith in, to rely on.

pisteuo (W.E. Vine): To believe, to be persuaded of and hence, to place confidence in, to trust, signifies, in this sense of the word, relience upon, not mere credence.

pistis (W.E. Vine): Primarily, firm persuasion, a conviction based upon hearing.

From these definitions I think that the nature of faith starts to emerge. Faith is a firm persuasion or trust that we can have. It is a static thing, hence the noun form of pistis. Yet faith can also be an active thing, and that we see in pisteuo and the use of the English word “believe”. Believing is faith in action. Believing is doing because of faith.

Faith is progressive. We know this because of the references and admonitions to grow in faith. Everyone starts with a given portion of faith.

For I say, through the grace given unto me, to every man that is among you, not to think of himself more highly than he ought to think; but to think soberly, according as God hath dealt to every man the measure of faith.

Romans 12:3

And then we have the opportunity to increase our faith.

So then faith cometh by hearing, and hearing by the word of God.
Romans 10:17

The Purpose Of Faith

What then is the purpose of faith? The Lord must surely have had a design to equip all with that initial portion of faith. We find that faith is how we appropriate the grace that the Lord brings to the human race.

But now the righteousness of God without the law is manifested, being witnessed by the law and the prophets; Even the righteousness of God which is by faith of Jesus Christ unto all and upon all them that believe: for there is no difference: For all have sinned, and come short of the glory of God; Being justified freely by his grace through the redemption that is in Christ Jesus: Whom God hath set forth to be a propitiation through faith in his blood, to declare his righteousness for the remission of sins that are past, through the forbearance of God; To declare, I say, at this time his righteousness: that he might be just, and the justifier of him which believeth in Jesus.
Romans 3:21-26

God’s grace was poured out in the redemption, the sacrifice, of Jesus Christ. He is our propitiation, the one who made the ultimate sacrifice on our behalf to pay the price of our sins. It is faith that enables us to claim that propitiation by our belief in Jesus. Knowing that belief is faith in action, our active faith in Jesus Christ as Messiah who died for our sins brings the righteousness of God upon us.

Life-Changing Faith

Faith is a life changing power. We generally find it in two forms. The first is Saving Faith and the second is Continuing Faith.

Bro. Bernard explains saving faith as acceptance of the gospel of Jesus Christ as the sole means of our salvation and appropriation (application) of that gospel to our lives by obedience to its requirements. That’s a wonderful definition and I believe it’s accurate, but it’s not how I want to describe saving faith.

I believe that saving faith is faith that motivates you to that which is required to be saved. It is enough faith to obey the teaching that the apostle Peter gave on the day of Pentecost when the Spirit of God was first poured out. It is faith that drives a person to repent of their sins, to request baptism by immersion in the name of Jesus and then to seek for the infilling of the Holy Ghost, with the evidence of speaking in tongues. That’s what I call saving faith.

Continuing faith is simply saving faith that does not stop. The initial salvation experience is undertaken one time, but the faith that drove a person to seek salvation can also drive a person to live a life pleasing to the Lord.

Faith Combined

Faith, powerful as it is, acts as a catalyst when combined with obedience or works. Faith takes obedience and works to their highest levels. It can be argued that without faith they are nothing, so a firm faith is to be sought first so that obedience and works may be layered on top.

Paul had much to say about obedience. Including that obedience was one of the criteria for him being an apostle.

By whom we have received grace and apostleship, for obedience to the faith among all nations, for his name:
Romans 1:5

Many people have had the gospel message preached to them, yet there are those who have heard it who have not obeyed it. Their portion of faith allowed them to hear it, perhaps even to understand it, but their obedience was lacking and thus they are lost.

But they have not all obeyed the gospel. For Esaias saith, Lord, who hath believed our report?
Romans 10:16

The mystery of the Messiah and the fusing of God and flesh, was explicitly taught so that the nations of the world would be obedient to their faith.

But now is made manifest, and by the scriptures of the prophets, according to the commandment of the everlasting God, made known to all nations for the obedience of faith:
Romans 16:26

Luke tells us that many of the priests in Jerusalem were obedient to their faith.

And the word of God increased; and the number of the disciples multiplied in Jerusalem greatly; and a great company of the priests were obedient to the faith.
Acts 6:7

And the writer of Hebrews directly ties salvation and obedience together. There is no salvation without obedience.

And being made perfect, he became the author of eternal salvation unto all them that obey him;

Hebrews 5:9

Works are another natural pairing with faith. Where there is saving or continuing faith, there is naturally expected to be good works. Paul explained this is his letter to Titus.

This is a faithful saying, and these things I will that thou affirm constantly, that they which have believed in God might be careful to maintain good works. These things are good and profitable unto men.
Titus 3:8

And it doesn’t take much exposure to the book of James to know that James robustly expressed a direct relationship between works and faith. James goes as far as to explain that your salvation is at risk if you don’t have works.

What _doth it_ profit, my brethren, though a man say he hath faith, and have not works? can faith save him?
James 2:14

Not that we are saved by works. No, absolutely not. But, works are an external evidence that we have experienced saving faith and have continuing faith. This is not unlike speaking in tongues being the initial and external evidence that someone has received the Holy Ghost. We can know that sufficient faith is in someone’s life by observing their works.

Even so faith, if it hath not works, is dead, being alone. Yea, a man may say, Thou hast faith, and I have works: shew me thy faith without thy works, and I will shew thee my faith by my works. Thou believest that there is one God; thou doest well: the devils also believe, and tremble. But wilt thou know, O vain man, that faith without works is dead? Was not Abraham our father justified by works, when he had offered Isaac his son upon the altar? Seest thou how faith wrought with his works, and by works was faith made perfect? And the scripture was fulfilled which saith, Abraham believed God, and it was imputed unto him for righteousness: and he was called the Friend of God. Ye see then how that by works a man is justified, and not by faith only. Likewise also was not Rahab the harlot justified by works, when she had received the messengers, and had sent them out another way? For as the body without the spirit is dead, so faith without works is dead also.
James 2:17-26

Say That Again?

Let me try to wrap this up neatly and put a bow on it.

Faith is a firm certainty in something. Here I am speaking of biblical faith, so that would be a firm certainty in God: his existance, his word, his power and his offer of salvation to this fallen world (otherwise known as grace). That firm certainty naturally expresses itself with actions. We call these saving faith, continuing faith and good works. Saving faith is faith in action, also known as belief, and it motivates us to seek a full and deep relationship with the Lord. Continuing faith is our understanding of the necessity to maintain that relationship and good works are kindnesses that flow out of the saved believer towards their fellow man.

It is also commonly explained that faith is how we access the grace of God, but where is the fun in explaining something so sucinctly when you can use a thousand words instead?