Leaders, Followers, and …

Some people lead, some people follow, some people blend in. Those that lead stand out, if to no one else than to those that they lead. Those that follow rarely seek notice and if so they principally seek recognition from their leaders.

Those that blend in though are not so easily characterized. Perhaps they fear persecution because they are different. Perhaps they suffer from social anxiety disorders of one form or another. Or perhaps they just enjoy what they are doing and don’t want to be bothered with being responsible for the care and maintenance of followers.

Often, they are remarkably skilled at a skill that I think of as leading from the rear. They are able to influence nominal leaders such that they do what the person who blends in wants them to. Those influenced in this way are often wary of the person doing the blending in and yet they are influenced all the same.

I have, no doubt, oversimplified here. And yet, I think I’ve identified some stereotypes that are actually typical of any population large enough to have a normal distribution.

And so, to bed. I am too tired to take this idea any further. Let me know what you think. Which type are you?

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

Because It’s Difficult

I read an article today. It was one of those articles organized around a list of some sort. This one was a list of ways that Isaac Asimov succeeded as a writer. They were all good. Some of them were inspiring. But in the final analysis he admitted that he worked hard at it. He asserted that nothing that was worth while was ever easy.

One of his techniques for dealing with being stuck was to set the project that had him stymied aside and work on something else. That is a good technique. I have used it myself on occasion. I would use it more if I wrote full time for a living. But I have set myself up in an artificially difficult situation. I have chosen to impose a daily deadline on my blog post.

Writing under a deadline is different. You can’t always set the project aside and work on something else. You have to pick a topic and run with it. Occasionally, you have to start over. I make it a practice to save my abortive attempts. You never know when you might figure out a way to salvage them.

Working to a deadline is stressful. But the satisfaction of writing something worthwhile within the constraints of the deadline is even more satisfying than writing the same article unconstrained by time.

Oh and, you never get stuck when you’re writing under a deadline. You don’t have time to get stuck. You write things iteratively, first listing the main points that you intend to cover in the article. And then, you break the points down and as you catalogue each one, you add in the details.

And then you’re finished. But you’re not. You’ve made your points and you’ve written the story, beginning, middle, and end, but you’ve still got to read what you’ve written. And, there’s no time to let it sit and allow you to regain your composure. You’ve go to edit, rewrite whatever needs rewriting, and eventually, you’ll find yourself putting the last touches on it, correcting the errors that jumped out at you, and accepting the ones that didn’t.

You press publish and accept what you’ve done for what it is and start thinking about what you’re going to write for tomorrow. It’s hard to write a blog post daily. It wouldn’t be worth doing if it wasn’t.

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

The Sherlock Finale

I watched what may very well be the last Mark Gattis / Steven Moffat Sherlock tonight. It was riveting. I refuse to discuss the details of the plot as I think anyone with any interest in the show at all needs to see this one with no spoilers.

Instead, I want to explore an aspect of the show that both amazes and baffles me. How does one captures a strong visual passage in a screenplay? I think the montage at the end of this episode is an example of a visual passage that says so much more than words could ever say. How does one capture those images in a script? Or does one? Perhaps this is an area where the director and the cinematographer collaborate with the editor to create something that transcends words.

Was the idea there in the script? The episode would be unfinished if it wasn’t. I have to believe that the writer had the idea upon which the sequence was based. Did he sketch the images? Did he write pages of descriptions? Or was it all just a matter of shooting enough footage of the general topics that the screenwriter alluded to in the script and then trusting to luck and the brilliance of the editor to compose such a singularly beautiful statement?

Perhaps I’ll never know what happened in the creation of this episode. That only leaves it for me to appreciate it. If they ever produce another season of Sherlock, they have their jobs cut out for them. This season finale will be a hard act to follow.

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

More Anglophilia

My wife and I both enjoy British television shows. She recently bought an app for our AppleTV that allows us to watch live TV as it streams from broadcasters around the world. In particular, this means that we can watch BBC programs as soon as they come out instead of having to wait for them to shows up on one of the channels in the United States.

Not only can we see the popular new British shows as they premiere but we can also watch the ones that are not even made available anywhere else in the world. For example, we have developed a taste for British game shows and panel shows. Even their reruns of television shows from the fifties and sixties are interesting and new to us. We didn’t get to see them when they first ran and in some cases they have provided background that has helped us appreciate references that were made to them in later shows.

The major problem is the time difference between here and the UK. Their evening shows begin here around noon. Unless they rebroadcast a show in the middle of the night, we don’t get to see them except on weekends. I am considering purchasing a DVR to time shift them. Like all such loopholes, I suspect these too will be closed soon. But in the mean time, we are enjoying catching up on as much British Television as we can handle.

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

LightTable Makes Clojure Development Easier

There is a program called LightTable. It is an Integrated Development Environment or IDE. An IDE is a program that programmers use to write programs. The nifty feature of this IDE is that it will run your program as you write it and show you the results of every command in the program as you type new ones in.

It is named after the device that photographer use to sort slides and negatives. The photographic light table is a box with a lamp inside of it and a translucent glass top that the photographer sets the negatives on top of. The light shines through the negatives allowing the photographer to sort through them and find the one they are looking for.

The principle language that LightTable was initially written to support is called Clojure. It is an updated version of the language Lisp. Like most Lisp dialects, Clojure is a dynamic language. This means that you interact with it using a piece of code called a Read-Eval-Print-Loop usually shortened to REPL. The REPL reads an expression, evaluates it, then prints the result, over and over again in a loop.

If the typical way of interacting with Clojure is through a REPL, why would one need an IDE that shows you the values of all of the expressions in the program at once? The difference is that the REPL only evaluates each expression once as it reads it in. LightTable evaluates all of the expressions in the current buffer every time you enter one or edit an expression so that it is complete. This helps the programmer to avoid mistakes by catching them as soon as they are made.

LightTable supports plugin extensions so it can be modified to support other popular languages such as Ruby, PHP, Go, Perl, Python, Julia, and many others. It also integrates nicely with Leiningen, a build tool written for managing Clojure projects.

I intend to develop at least one project in Clojure using LightTable. If it goes well, I have several other projects in the wings. I also have some ideas for using Clojure for several work related projects. That would just be one more way that I can make my job into something that I enjoy more every day.

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

The Annual HARC/NARA Combined Meeting

It is the annual combined Huntsville Amateur Radio Club (HARC)/North Alabama Repeater Association (NARA) meeting. This meeting is generally the first meeting after New Years and the program is a state of the North Alabama Repeaters report along with a preview of some of the enhancements that are planned for the coming year. It is probably the largest meeting of hams in Huntsville except for the annual ham fest that is in August.

The membership numbers of HARC have been growing in the past couple of years. I don’t know for sure but I suspect the membership in NARA has grown as well. I’m not exactly sure why. I suspect it is a combination of several factors. For one thing, the license structure has gotten simpler in recent years. The morse code requirement has been dropped and there are only three levels of license instead of five. The tests questions and answers are published so that you can target your study to the specific topics that you will be tested upon.

Another factor is the proliferation of less expensive ham radio gear. Many of the new radios are based on high speed digital circuitry instead of analog circuits. This results in much more capable radios that are cheaper to build. It also makes home brew radios simpler to design and put together.

And yet another factor is a resurgence in interest in providing emergency communications and relief during disasters both natural and man made. There are also a number of hams that are still interested in the competitive nature of collecting contacts with other hams in other countries around the world. There is also an element of competition during contests to see how many contacts one can make in a given time period.

Whatever the reason, the hobby is growing faster than at any other time that I remember and I’ve been following it for well over forty years. I just thought of another reason that it may be growing so much lately. People have gotten a taste for global social interaction from the internet but they are getting a bit tired of the bad behavior that seems so prevalent in many venues on the internet. Radio is largely self policing and is a much friendlier community in general than the internet. Of course, your mileage may vary.

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

My Mother Would Be Proud

Writing for yourself is easy. If you want to, you can sit and type the same word over and over or you can describe the antics of your pets vying for your attention while you struggle to meet your quota of words for the day. A popular ploy is to discuss at length how many words you have written so far compared to your goal.

Writing for other people is hard. You have to concern yourself with such issues as choosing a topic that people might be interested in reading. You don’t want to appear to be an ignorant bumpkin so you want to check your spelling and grammar. You want to cover all the salient points without belaboring your point.

Take that already considerable challenge and repeat it daily. And if that weren’t difficult enough, try to do it with little to no feedback about how well you are doing.

If it were easy, it wouldn’t be as rewarding to finally accomplish. I’m not saying that I’ve done it yet. I’m just reminding myself why I keep trying. I do it to improve my writing skills. I do it to carry on a time honored practice. I do it to inspire others to put their thinking caps on and put words on the page and write something that I want to read.

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

More Rant

As my colleague Danny Cutts pointed out in a comment on my post yesterday, I criticized the status quo in software development without making any constructive suggestions for how language selection ought to be done.

The short answer to that question is that it is a topic that sorely needs research. There are, in fact people in academia all over the world that are investigating these issues. There are many interesting approaches. I have been impressed by the results obtained by using languages that enforce constraints against mutable data and encourage programmers to avoid side effects.

I am an admitted fan of Lisp and I think that Clojure has done the best job of all the modern Lisps of advancing the state of the art of Lisp like languages. Not only has it made data immutable by default, it has also unified the operations upon collections of all sorts. It has also baked in thread safety to the point that it’s hard to get concurrency wrong.

And the final aspect boosting Clojure over the top in the comparison of modern Lisp implementations is the fact that it is built on top of the JVM and provides direct access to all those incredible libraries available for the Java platform. It is truly the best of both worlds.

Another language that is oft maligned but is far better than it is widely thought to be is Javascript. It has long suffered from lack of respect due largely to being forced out the door prematurely for marketing reasons and then forced to live with its unfortunate choices due to its wide spread adoption as the universal web scripting language.

Modern implementations, Node.js on the server, and the evangelism of Douglas Crockford have all gone a long way toward improving Javascript’s reputation not to mention it’s attractiveness as a generic platform for application development.

Languages should be chosen to best address the needs of the problem domain. That is much easier said than done. We are suffering from too many options. People try to overcome that problem by artificially constraining the list of choices. Perhaps they would do better to use the prescription that the Unix community suggests (sometimes attributed to Kent Beck):

  1. Make it work.
  2. Make it right.
  3. Make it fast.

What that means is, first hack out a naive solution, sometimes referred to as the simplest thing that might work. Then, refine the solution to cover all the edge cases that you overlooked in the prototype. Finally, instrument the code to find out where it is spending most of its time and concentrate on optimizing that part of the code.

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

A Short Rant from My Soapbox

Everyone has preferences. Chocolate over vanilla, rock music over country music, and so on. Never is that any more apparent than in programmer’s preferences for programming languages. Often it is for the language that they learned first but then sometimes you find a programmer who has found another language that is so much better for the task at hand that they becoming a fanatic advocate for the new language.

I am a connoisseur of programming languages and after forty years of learning as many new languages as I could put my hands on I have finally had a revelation. Programming languages all have strengths and weaknesses. These vary greatly from language to language. Problems that programmers set out to solve have a wide variety of attributes. Some languages are better for solving some problems than others.

Now given any particular programmer, you have a fairly unique set of languages that they know and problems that they are comfortable solving. This influences their preferences for languages. They will, in fact, be more productive using a language that fits the problem they are trying to solve and is familiar to the programmer.

However, it is the mark of a master programmer to examine the problem at hand and pick the language to write the solution in based on the characteristics of the problem. This is particularly rare because many companies allow management, that have only a vague understanding of the issues involved in writing a significant piece of software, determine which programming language the programmer will be required to use.

I tried to come up with some pithy analogy to illustrate how wrong this is but it is so uniquely and totally wrong that I could think of no analogy that came close to illustrating my point.

The root of this problem stems from the mistaken belief that there is one language that is the best to program all problems with. I think that is fundamentally mistaken. If you read the work of Kurt Gödel he proved, somewhat paraphrased, that a formal system could either be consistent or complete. Programming languages are by definition consistent. Therefore, they can not be complete, which is to say, that no one computer language can express the solution to all problems.

Management means well. Most people do. They want to do their job to the best of their ability. They think that by insisting that their programmers use this or that language, they are reducing the risk of failure. In fact, they are not. They are increasing the risk of failure by limiting the domain from which solutions can be gleaned.

This is not to give the programmer carte blanche to use any language they like just because it is exciting or they are comfortable programming in it. Rather the programmer needs to be trained to recognize the relevant attributes of problems and how to evaluate programming languages to find an appropriate one to use to solve it. In short they need to be experienced professionals.

The situation is made even worse by the fact that, while we wouldn’t dream of having an automotive engineer design an airplane, we somehow have the idea that any joker can write software. It’s true. Anyone can write a program. The quality of the program that they write will vary greatly with their experience and aptitude though.

When I joined the company where I work some twenty five years ago, managers did not have computers. Anything with a keyboard was considered secretarial work and beneath their station. This has changed as the old school managers have retired one by one and been replaced by a spreadsheet wielding younger generation.

I think the next big paradigm shift that needs to happen is to realize that programming is an engineering discipline deserving the respect of any of the other engineering disciplines. Not only that but it needs to be understood that being trained in one of the other engineering disciplines doesn’t automatically make you a good programmer.

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

Desperately Awaiting AI

I have been reading about the history of the development of the electronic programmable computer recently. Even when you consider the development of Colossus which wasn’t acknowledged by the UK until the 70’s, the origin of the programmable electronic computer was around 1943. That means that computers are approximately seventy three years old. That is longer than I’ve been alive but in terms of maturity of the field, I think it is still early days.

We have learned a number of important principles of computing but there are plenty more to be discovered. It would be incredibly short sighted to think that we have discovered even the tip of the iceberg when it comes to algorithms.  The age of distributed computing has barely started. Artificial Intelligence is still relegated to dank holes in the ground where it can be ignored.

That is except for such organizations as Google which continues the search for a plugin capable of producing the illusive artificial intelligence that we have been waiting for. We’ve waited since the late fifties straight through into the eighties. It seems that it was always going to be here in approximately five yours. Never have so many estimated so poorly.

We have had AI winters and AI springs. We have seen AIs in movies and television shows. We are told by some experts that AI emerged quietly in the 90’s. Ray Kurtzweil says it is due twenty years from now. I am running out of time. I need a Singularity sooner than later. Or at least functional immortality so that I can out wait the coming of AI.

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