John Lindal’s Blog

Humility

I recently read The Language of God: A Scientist Presents Evidence for Belief because it was recommended to me by a retired pastor who is a friend of my wife. Now I recommend it, too. The science is clearly presented, and the arguments for the existence of God are worth considering.

When I went to find the book on Amazon, I discovered that there is a whole cottage industry based on writing books like this. I was a bit surprised, but I really shouldn’t be. People on both sides of the debate never cease to propound their opposing views. Why shouldn’t there be a group who tries to bridge the chasm?

The sad part is that all three groups mostly get it wrong. Regardless of the point of view — be it bible only, bible+science, or science only — they almost always fall into the trap of thinking that they actually know how the universe really works.

The fact is, we don’t.

We cannot prove that God exists. If He does not exist, we are left wondering how the universe came to exist and what our purpose is, if any. If He does exist, we are left wondering how He came to exist and, if you accept the Bible, why He behaves the way He does.

It is quite humbling to admit that we just don’t know what is really going on. It is also scary, however, which is probably why most people cling desperately to one viewpoint or another. (This applies to all religions, not just Christianity.)

However, if people would accept this dose of humility, then I think we would all find it much easier to get along.

Chuck E. Cheese

We just escaped from the ear-splitting, crass, insult that is Chuck E. Cheese. No offense to the parents who scheduled the birthday party there, but the place is intolerable. While I carried my daughter to the car, she listed out everything she doesn’t want for her next birthday party: no loud music, no screaming children, no Chuck E. Cheese. Wise kid. From now on, I’m referring to the place as Yuck E. Cheese.

Time Trap

I just finished Keith Laumer’s Time Trap, published by Baen Books. I found it interesting that Laumer’s time trap worked exactly the same way as in Groundhog Day: It reset every 24 hours, but you remembered everything from the previous cycles. If you were hurt or killed, you woke up whole again at the reset.

New Furniture

My daughter’s new furniture arrived yesterday. She has outgrown her toddler bed, and we found the perfect bedroom collection at easylife. It was discontinued, so we got the floor model at 40% off. Of course, that meant scratches, and after it was delivered, we discovered that the bottom of one of the drawers was broken loose, but nothing that a few nails couldn’t fix!

Since we want her bed to be against the wall, away from the window, one of the two under-the-bed drawer sets wouldn’t make any sense under the bed, so we put it in the closet. It fits so perfectly that I’m tempted to start believing in Intelligent Design

The Long Road to Hell

A friend just introduced me to Variadic Templates in C++0x. When will they admit that they just plain started from the wrong place? Their example of how to print a comma-separated list of arbitrary values, which is impossible in C++ without variadic templates, is so trivial in an untyped language that nobody would bother to discuss it.

Has it really never occurred to the C++ crowd that they should start with a loosely typed language and then add in an option for compile-time type checking? Objective C actually does this. A function parameter can be id, which means it accepts anything, or it can be a type, which means that it accepts that class or any subclass, or it can be a Protocol, which means that it accepts any class which implements the required methods. (Protocols also feature prominently in the new language, Go.)

The only flaws I can see in Objective C are (1) id only accepts objects, not primitives, and (2) constructors return id, so there is no type checking when an object is created. Java fixes the former this via autoboxing, but Java doesn’t have the concept of a Protocol and reflection is very painful.

One could argue that another flaw in Objective C is the lack of private functions. However, this can be solved the same was as in JavaScript: static functions, which are accessible only to other functions declared in the same source file.

Eee PC Back Online

I recently made the grave mistake of upgrading my Eeebuntu installation to the latest Ubuntu, after which support for my external monitor vanished. Ouch! I finally have it working again, after starting from a clean install off the Eeebuntu CD. This time around, it went a bit faster, since I knew that networking would not work without a kernel upgrade, so I downloaded it before the re-install. Thank goodness I put /home on a separate partition!

Vacation in Buffalo

The US Airways planes seem old, but their pilots really know how to land. On our flight from LAX to Charlotte, the landing was so smooth that I didn’t even realize we were on the ground until they reversed the engines to slow down. Later, when we landed in Buffalo, there was turbulence at ground level, but the pilot still set us down smoothly. The service on both flights was also great. Just remember to bring your own food

In Buffalo, we visited SUNY Buffalo, my wife’s alma mater. We also ate Buffalo wings at Duffs, a local place that knows how to do it right. The fall colors were beautiful.

Next, we drove to Niagara Falls. I wasn’t impressed by the Behind the Falls tour, but the view from our room in the Marriott was fantastic. The dinner at the Mandarin, a chinese buffet a few miles off the strip, was even better. If you want a good breakfast, eat at Falls Manor. They also have a motel, if you don’t want to pay for a hotel on the strip. In fact, the service at the Marriott in Niagara was terrible. This was quite surprising since the service at the Marriott in Buffalo was terrific.

Our final destination was a visit to a couple in Ontario (CA) whom my wife knew from long before she met me. It was great to finally meet them! The husband is a retired pastor. He encouraged me to continue digging into Evolutionary Theism.

We drove back to Buffalo through a persistent drizzle. It was a nice reminder that I only want to visit

Fortune Cookies

I’ve finally found a fortune cookie with a prediction that I don’t want to come true:

Your most memorable dream will come true.

My most memorable dreams turn into stories, and while I enjoy writing them, I certainly wouldn’t want them to happen!

Encapsulation & Polymorphism

Most programmers nowadays are educated with Java. As Joel discusses, this eliminates the need to teach many difficult topics such as pointers. Two topics that Joel does not dig into are encapsulation and polymorphism.

Encapsulation is the fundamental concept of Object Oriented Programming (OOP). In C++ and Java, this translates to objects encapsulating tightly coupled data and functions. However, since all messages between objects are function calls, it is very easy for tight coupling to creep in. This is why some people campaign against getters and setters: overuse can lead to tightly coupled data and functions residing in separate objects.

In addition, C++ and Java force concepts to be mixed together because polymorphism is implemented primarily via inheritance. Polymorphism boils down to different behavior in response to the same message. Coupling this with inheritance, which is merely one way to re-use code, requires programmers to either get stuck in a straight jacket of single inheritance or go hog wild with mix-in interfaces. The latter is better, but it can still get very confusing.

To see encapsulation and polymorphism clearly, it helps to consider other implementations.

The purest forms of encapsulation occur when the boundaries are strongest: interacting processes on separate machines, e.g., web services or XHR/JSONRequest. In this context, interaction requires network traffic, and efficient systems strive to minimize this. Interestingly, this does not lead to minimal interfaces such as what you find in C libraries where each function does one small, simple operation. Instead, each interaction accomplishes as much as possible to minimize the network traffic. Getters and setters are non-existent, except in special cases when that is all that is required.

The purest forms of polymorphism occur in weakly typed languages. Objective C allows any message to be sent to any object. If the object does not implement the message, it can either delegate it to another object or throw a run-time error. The same is true for JavaScript, Perl, Python, etc., though language support for delegation varies.

How can we apply this to C++ or Java? Since encapsulation is weakly enforced by the language, it helps to encapsulate functionality, i.e., modules, instead of individual classes. Modules are much less likely to need getters or setters. Instead, they normally expose higher level actions. Messaging frameworks similiar to Objective C can been built in strongly typed languages, e.g., signals-and-slots or JBroadcaster, but it typically requires manually writing or automatically generating dispatching and receiving code.

Along with questions about pointers and functional programming, digging into a person’s understanding of encapsulation and polymorphism makes for a good technical interview.

C++

Lots of smart people hate C++, but I cannot get myself to agree. It’s true that C++ is vastly more complex than C, but this complexity can be managed. When managed properly, the additional features of C++ are very powerful extensions to C. Because one must be careful, many people seem to feel that Java is much easier, but that is really a people problem. Bad programmers can write spaghetti in any language.

Let’s examine the alternatives to C++. Java is the closest one. I believe it has everything C++ has. It also has garbage collection. This beats manual memory management hands down. Garbage collection enables usable exceptions. Java generics are definitely easier to use than C++ templates, but I feel that this is mostly due to the system linker still being in the stone age — though there is virtue in simplicity. Java also has reflection, which is way beyond the primitive RTTI support in C++: dynamic_cast and type_info. But the reflection API is bulky and very tricky to use with generics. In a strongly typed language, it is best to avoid the need for run-time type information and rely instead on polymorphism. Also, Java comes with a huge run time, the JVM, and this does not run lean, though the need to package it with your program has thankfully disappeared on many platforms.

Another class of alternatives is weakly typed languages such as JavaScript, Objective C, Perl, and Python. These are wonderful for smaller programs. Their expressiveness is much higher than C++, so the source code is much shorter. Since they are weakly typed, polymorphism does not rely on inheritance. You can invoke any method on any object. The cost of this flexibility is that everything is a run-time error. There is no way to know whether or not a call will succeed. In the worst case, it depends on the state of the program when the call is made, so you must have integration tests (not units tests) that exercise every conceivable code path. As with C++, this complexity can and must be managed, but unlike the static complexity of the C++ language, this complexity is dynamic, so it grows exponentially with the size of the program.

Given the alternatives, I think that C++ still has a place, just as C does. When C++ does make sense, it is always worth asking whether Java is a better choice, but I do not think the answer is always yes.

Update (10/18/2009): After reading this post and remembering some of the features of C++ that I suppressed after reading Meyers’ Effective C++, I have to admit there is much to hate about C++. The only explanation for why it doesn’t bother me day-to-day is that I am using a very carefully selected subset of the language. I’m certainly using more than 20%, but all of what I use, I use in moderation.