Occasional Comment

Most people are most eloquent in their native tongue and the same seems to be true of programming languages. There are those polyglots that excel at any language they learn but it is often more true than funny what they say about  a good Fortran programmer being able to write Fortran in any language. Only in my case I would have to substitute C for Fortran.

Many years of study and coding in Java, Ruby, Python, Lisp, and various other languages has softened my C accent but it is there for those that know to look for it.

I think it can also be said that the first language in which you encounter a particular paradigm colors your attitude toward that paradigm. For instance, I first learned about object oriented programming in Java. Soon after I encountered it in CLOS, the object extension to Common Lisp. I struggled mightily to understand CLOS. Now, some thirty years later I have realized why I had problems understanding it.

Java, like most of the strongly typed, statically compiled languages, tries to constrain functions that operate upon an object to be encapsulated in it’s class. CLOS, on the other hand, considered classes to be an extension of data types. Methods, with their type driven dispatch, were independent from classes.

Eventually, I grasped how methods worked in Lisp. It was a long time until I was comfortable with it though and I still catch myself falling back into conflating types with method encapsulation.

So, I was thrilled to discover that Julia followed the CLOS model of specifying data hierarchy with object types and letting method dispatch be orthogonal to them. There is much to be learned from such an elegantly designed language.

I obsess like this with each new programming language that incorporates what we have learned about expressing ourselves about data and functions in ever more eloquent fashions. It is part and parcel of my infatuation with programming languages. In that, I hope you will indulge me.

---

Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.

Watching a show on the placebo effect on the BBC tonight I realized that the power of the mind to control the chemistry of the body is far more profound than conventional western science would expect. In case after case, the show described studies where patients had profoundly positive results with only placebos and caring treatment from their physician. In some cases, the patients were told they were receiving placebos and yet they still experienced positive results.

The show described one study where a surgeon studied the results of conducting a placebo procedure instead of a very effective surgical treatment. In one of the cases presented, the patient had received the actual procedure for a previous injury so she knew what the real procedure felt like and yet she had positive results from the placebo procedure.

The show went on to explore the practice of medical hypnosis and studies that focused on the impact of positive suggestions from the physician in the case where all patients received placebo acupuncture. It became clear that the operative factor was the caring attention and confidence of the physician.

I have studied meditation and the western mystery tradition. I believe that the effectiveness of these so called magical traditions are closely akin to that of the placebo effect and the key thing to understand here is that the placebo effect is real. The results, while not universal or in all cases permanent, are verifiable with conventional, repeatable scientific studies. This indicates to me that we have only studied the tip of the iceberg when it comes to the power of the mind over matter, in particular the body.

---

Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.

I’ve been coding the Countdown Numbers game that we designed several days ago in the Julia language this afternoon and evening. So far, I’ve implemented the number selection and target selection functions. I’m currently working on the code that generates potential solutions and evaluates them using the criteria established in the definition of the game.

I am using the Juno development environment. It is developed as a plugin for the Atom editor. So far the only criticism I have of it is that it is a little overly aggressive with suggestions for autocompletion. There is probably a configuration option to tone down the aggression but I was so eager to start coding that I haven’t taken time to read the Juno tutorial.

My first impressions of Julia are very favorable. It seems to adopt the best features of a bunch of the best dynamic languages while managing to avoid feeling like a hodgepodge of features. It is built with the best of current compiler technology and consequently delivers a very performant end product.

Several of its features in particular impress me. First and foremost, it is homoiconic, that is to say, the compiled objects in the language are expressed as data elements of the language and as such lend themselves to dynamic manipulation. This supports the second impressive feature, it supports a full blown, Lisp like macro language. Macros allow you to easily extend the syntax of the language. You don’t need them often but when you do, they can turn writing and maintaining a complex code base into a walk in the park.

It also has full blown multiple dispatch, which is to say, you can have a function that has separate implementations depending on the types of arguments that you pass into it. For example, you might have a function that computes the area of a rectangle. If you passed in parameters of type inches you would be dispatched to a function that computed the area of a rectangle in inches from the height and width of the rectangle in inches. Or, if you passed in one parameter in inches and the other parameter in millimeters, it would be dispatched to another function that converted the parameters in millimeters to inches and then called the original function to compute the area in inches.

Behind most of these features is a type system that helps insure your computations make sense without burdening you with declaring variables, particular when the  compiler can infer what they are from context without your explicit intervention.

The last thing I’ll say tonight about Julia is that the code just looks clean. There is no extraneous boilerplate that tends to clutter up many other languages (cough cough java cough cough).

As promised in the blog post where we designed the Countdown Numbers game, I will walk you through the implementation of it when I get it written. I’ll also discuss why I made tweaks to the design while implementing it.

Go download Julia and have a look at the manual that is available there. It is a good place to start.  If you are impatient, Learn Julia in a few minutes is a good way to get up to speed fast, especially if you have written any Python or Ruby code.

---

Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.

It is interesting to read about programming languages. They are very similar to natural languages in many regards. For instance, you tend to prefer the first language that you learn or, failing that, languages that are similar to it. Some times people try to make excuses along the lines of “I know how to do things in that language.”

The languages grow and evolve over time. Idioms arise and fall into disuse as more expressive ones are found. The best languages encourage evolution through function definition at minimum and often through macro definition and expansion.

Macros have always intrigued me. They are code that rewrites code. They help bring the expression of a solution closer to the form that it was originally conceived in the programmer’s mind.

When I first learned about macros, I was convinced that they were a necessary, if perhaps not sufficient, attribute of a language in which an artificial intelligence would be written. I have since come to believe that artificial intelligence will emerge from the substrate of the protocols and distributed computing facilities of the internet. I still suspect macros will be involved in some way.

What is a macro? It is a piece of code that instead of encoding a solution directly, allows a programmer to specify how one expression of a solution can be transformed to another, often more complex, expression of an equivalent solution. They often take the form of templates that are filled in with arguments inserted from the macro invocation, after which the resulting code is evaluated as it would be if a programmer had written it directly.

---

Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.

I’m extremely tired tonight. I am going to mention a few tidbits that I discovered today and then call it a night. I discovered that the Julia programming language had evolved a good bit since I last looked at it. I started reading a tutorial on it and took a quick look at the manual.

Second, I discover the Pony language. I am still investigating what it is but on the surface it appears to be a very pragmatic functional language based on the actor-model paradigm. I’m still getting my head around what that means. It will probably be good for a blog or two when I start to understand it.

I did have a mini-epiphany while I was writing my journal entry this morning. It occurred to me that I didn’t actually need to shuffle the number cards in the Countdown numbers implementation. It is sufficient to pick them randomly and make sure that I don’t pick the same card twice. I figured out that this was a case where modeling the mechanisms that we use to try to insure arbitrariness in our distribution of cards in the real world, i.e. shuffling, was totally extraneous if I was depending on the arbitrariness of a pseudo-random number generator for that in the first place.

I know. I’m tired. I hope that last paragraph made sense. Hopefully I won’t be quite so tired when I write my blog tomorrow.

---

Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.

Last night I talked my way through the analysis and design of a program to solve the Countdown numbers game. Tonight I have spent some time attempting to implement this software using Clojure, a modern dialect of Lisp. In doing so, I discovered a blind spot in my programming experience. Clojure is a functional programming language. I’ve spent most of my life writing software in imperative and object oriented languages. I have studied the functional paradigm but I haven’t practiced it to any great extent. Tonight I’m going to discuss what that means and what I will do to move beyond this temporary hurdle.

Functional programming languages are based on the concept of mathematical functions. In pure functional programming languages all data is immutable and functions transform their input into their output with no side effects. That is fine in theory, but the valuable part of most programs, that is reading input from various devices and writing output to other devices for instance, are inherently entangled with side effects. You can’t read a keyboard twice and expect to get the same character unless the user just happens to type the same character twice in a row. To put it simply, the input function depends on the side effect that is the key that the user has pressed on the keyboard.

So, languages like Clojure make clearly defined distinctions between the bulk of the language that honors the functional principles and the non-functional parts of the language that allows practical work to be accomplished. This should be easy to get your mind around but it’s not.

In traditional imperative languages, we deal with variables which serve as containers to store values. We can store a value in the container and retrieve it later and it will still hold the value that we stored in it. In fact, the only way that we can change the value that it holds is to store a different value in the container. Since the container can only hold one value at a time, that clobbers the original value with the new one. This is fine in the case where you have a single processor executing a single instruction at a time.

But in the modern world few computers have a single processor in them and even if there is only one physical processor the software simulates multiple processors and multiple threads of execution. The problem arises when one of those threads stores a value in one of those variables that it shares with another thread, and then another thread decides to read it just as the first thread decides to change it. The results are unpredictable and account for one of the more difficult bugs to find in modern software.

We have been doing this kind of coding for decades now and there are text book solutions to the problem but they are complicated and easy to get wrong and Murphy, the patron saint of programmers, has his way more often than not.

Clojure has made a crucial distinction between values and identities. A value is constant. The number seven has a value that we can count on never to change. Now we might have two containers that can hold a number. The first one we give the identity X and the second we give the identity Y. We assign X the value 7, using a special mechanism that insures that no one will be able to read the contents of X until we have completed writing the value 7 into it.

The key thing to know about the difference between values and identities is that values don’t change and identities don’t actually hold values but rather point to them. Thus, if one thread has a copy of the pointer to the value that an identity was pointing to at one point in time, that value won’t change unpredictably when the identity is changed to point to another value.

This calls for a very different way of programming. You spend most of your time creating temporary values that don’t ever get changed and only rarely give a value a longer lived identity. The idioms of this style of programming are different. I am having to figure them out as I go. I also have to analyze them to decide which ones perform better than others.

In short, you can teach an old dog new tricks but you and the dog have to want to learn and be patient. When I manage to implement this algorithm in Clojure I will devote a blog post or several of them to walking through the solution.

---

Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.

This is an analysis and design of a program to allow someone to play the numbers game from the British game show Countdown on a computer. First we’ll review the rules of the game and then we’ll explore techniques for implementing them on a computer.

The numbers game is played with a board of cards containing numbers face down. There are four cards containing either 25, 50, 75, or 100, and twenty cards containing two each of the numbers from 1 to 10. The player specifies six cards to be drawn, between zero and four from the large numbers and the rest drawn from the small numbers. The numbers drawn are revealed and a random number between 0 and 999 is generated. The player then attempts to combine the six numbers using the four arithmetic functions, +, *, -, and /, in order to get as close as possible to the number generated. Ten points are awarded for matching the number exactly, seven points are awarded for an answer between 1 and 5 numbers from the target, and five points are awarded for an answer between 6 and 10 numbers from the target.

The generation of the target is a simple matter since all modern computer languages have a pseudo random number generator which, when combined with some arbitrary parameter such as a portion from the extremely small end of the system clock, provides a truly arbitrary result. For example, if the user were to press the button to generate a target at a time when the nanosecond portion of the system clock contained 345, you might multiply that number by the next pseudo random number returned by the generator and then scale it to be between 0 and 999.

The cards would be handled differently. First, we would declare an array of four big cards and 20 little cards. We would initialize those arrays with the values of the cards that are specified in the rules. Then, we would run an shuffling algorithm, some arbitrary number of times on the big number array, and another arbitrary number of times on the small number array.

The shuffling algorithm would work by generating a pair of distinct random number between zero and three in the case of the big numbers and between zero and nineteen in the case of the little numbers. These numbers would serve as indexes into the respective arrays. For example, you might generate 1 and 3 for the big number array. This would indicate that you should swap the element with an index of 1 with the element with an index of 3. You would repeat this operation some arbitrary number of times generated by calling the random number generator, scaling by a large number and then adding a large number to insure a large minimum number. If you generated a number between 0 and 100 and scaled it by 1000000 and then added 37584 as a minimum you would guarantee that the array would be shuffled between 37584 and 1037584 times. You would shuffle the small numbers in a similar fashion.

Now, given a target number between 1 and 999 and six cards containing numbers that can be used to derive the target, it only remains to give the player 30 seconds to come up with a solution to the problem. But how do we determine if the puzzle even has a solution?

First, we take every combination of the six numbers drawn taken one, two, three, four, five, or six at a time and we combine them using every possible combination of operators. We take each result and store it as either an exact match, a match plus or minus five from the target, a match between six and ten from the target, or else we discard it. Thus, we now know if the puzzle is solvable and we can check the answer that the player gives.

And that is how we analyze and design a program to play the Countdown numbers game. I will use this analysis to actually implement the game. Another time, I’ll analyze and design a program to play the Countdown letters game.

---

Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.

For the last three Sunday nights we have watched a three part series that tracked the history of the musical from the early twentieth century through the present. It reminded me of why I was so moved by musicals and even had ambitions to create rock musicals when I was a teenager.

In my case, other things distracted me and I never followed through with my ambition. What I discovered watching this series was exactly how amazing the intervening years have been. I have remained vaguely aware of many of the productions and even saw the movie versions of some of them, for example Rocky Horror Picture Show and Rent.

The thing that is almost universally true, however, is that a live performance will almost always put a filmed performance in its place. The energy of a live performance, complete with its high points and its occasional blemishes is unmatchable by the canned performance that a movie presents.

I was also reminded of all the wonderful musicals that I had somehow never managed to see, either on the stage or screen. Shows like Cats, Miss Saigon, and Avenue Q. I hope they will be revived by touring companies so that I can catch up on some of them.

---

Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.