Category: programming

Love the One You’re With

Twenty five years ago the computer industry was fraught with religious wars. There was the OS war that purported to be about which OS was the best for a personal computer. Similarly there was the programming language war. And, last but most certainly not least, there was the text editor war over which was the best editor for entering text into a computer.

There are many more options in each of these categories now. And, people still have strong opinions about which option they prefer. The religious zealotry has largely subsided though. People are finally more focused on getting the job done than they are finding the absolute best way to do something on a computer.

I have my opinions, particularly when it comes to text editors. Text editing is my bread and butter. I write programs, documents, and stories with a text editor. For years I was an emacs snob. Actually, it was more a matter of muscle memory. I had used emacs for so long that I no longer had to consciously think of a command, my fingers just type it when I thought about wanting to execute it. I have joked about muscle memory but it is true, I am immediately more productive when I sit down to a machine with emacs installed on it.

But part of the job of a senior developer is to help more junior developers figure out ways to be more productive. I could have taken the time to get emacs installed on the lab machines. There is a process and I’ve been told to feel free to do it. But on further consideration I have decided that I push past my comfort zone and learn more about the vi editor, or more specifically the vim editor.

Vi has been around since soon after the rise of the unix operating system. It was written by Bill Joy of Sun Microsystems. It is notable if only for the fact that it is delivered on practically every unix distribution in the world. It has a reasonably rich command set. I wanted to get past the point of having to look each one up in order to use it so I started using it to develop the various test cases that I am responsible for verifying.

I have only been using it in this capacity for a couple of days but I can report that it is much more capable than I would have thought. Over the years all the major programming text editors have added features like intelligent code formatting and keyword highlighting. Code highlighting can be very useful for calling attention to inadvertent typographical editors in your program.

There are other editors in the running today. For instance, gedit is the graphical text editor bundled with Linux. Atom is a saucy little editor written in javascript, formatted with CSS, and capable of syntax highlighting with the best of them. It has recently been upgraded to ease integration with GitHub.

These days the choice has boiled down to the answer to these questions: What editor does everyone else use? What are most of the developers on the project use to? What features are you most familiar with and which ones fit the type of uses you intend to demonstrate?

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

The Evolution of Programming Paradigms

My career as a programmer has spanned more than forty years. In that time I have seen a number of programming paradigms promise to make programming easier, more robust, and less error prone. Let’s review these paradigms in roughly chronological order.

Early in my career the latest advance in programming paradigms was Structured Programming.  The essential insight of Structured Programming was that programs should be written using a small set of control structures and that the primitive goto instruction should be shunned. The benefit was more readable code that could be more easily analyzed. The goto ridden code was often referred to as spaghetti code.

Next to come into vogue was the paradigm called Object Oriented Programming. Objects were intended to provide several benefits. First they were aimed at grouping functions with the data that it operated on. It also introduced the concept of encapsulation or data hiding. Data, and functions for that matter, that were not specified as public could not be accessed or modified by code outside the object.

Most popular Object Oriented languages were based on the idea of Classes that specified the data and functional template from which individual object instances were created. These Classes were often organized in a hierarchy such that the more general Classes specified the common data and functional characteristics of a group of objects. The more specific members of the class hierarchy would then add or override data or functional characteristics of the subclass to refine the representation and behavior of the instances of the subclass.

As it turns out, in most cases class hierarchies just added unnecessary complexity to programs. They also introduced problems such as what if you have a class that inherits from two different parent classes. For example, suppose that you had a BankAccount class that represented the ledger of a bank account, the deposits, the withdrawals, and the current balance. Suppose there was another class that represented a PrintableReport. Suppose that you wanted to create a class BankAccountReport that inherited attributes from both the BankAccount class and the PrintableReport class. Now here’s the quandary. Both superclasses have an operation called addItem. Which operation should the child class inherit, the one from BankAccount or the one from PrintableReport? This created so many problems that many Object Oriented languages only allowed a class to have a single super class.

Next to the scene was Aspect Oriented Programming. It’s claim to fame was a solution to the problem of multiple inheritance or, as it referred to it, cross cutting concerns. Aspects were a mechanism that allowed the programmer to conditionally alter the behavior of an object by modifying the behavior of a class without modifying its implementation. It did this by capturing calls to it’s methods and allowing the programmer to intervene before or after the call to the aspected operation of the underlying class.

The latest paradigm is not really new. Functional Programming goes back to the early days of Lisp. It says that functions, in the mathematical sense, should map inputs to outputs without causing any side effects. Functions should further be first class entities in the language. This means that they should be allowed to be stored in variables and passed as arguments to other functions.

Strict functional programming is difficult if not impossible to achieve practical results with. Most programs take input from somewhere and output results to somewhere. Taking input and outputting results are both violations of the constraint that the output of a function should depend solely on it’s input. Most functional languages have well defined accommodations for operations that aren’t strictly functional.

This was a whirlwind tour. I hope it gave an overview of the evolution of programming paradigms over the last forty years. Look these programming paradigms up on Wikipedia if you want to know more about them. Or if I have managed to confuse you totally.

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

The Purposes of Computer Programming Languages

Computer programming can be viewed on many levels. Superficially it is a means for specifying how a computer should perform a given task. If that were all it was, we could must enter a long sequence of numbers that correspond to the machine instructions to accomplish the task.

Modern computer languages go much further. They provide platforms for communicating, not only the specific tasks to accomplish but our assumptions about them, the structure of the data that they will manipulate, and the algorithms that will accomplish them.

But even beyond that, they provide a common language for people to talk to each other about programming tasks. As such, they evolve with the growth of our understanding of the activity of programming, its attributes, and the algorithms that are the final product of the activity.

To summarize, we write programs to enable the automated solution of computational problems by computers but also to communicate with each other about these computational processes. In the interest of clarity of communication, we have seen the trend of programming languages toward higher and higher levels of abstraction with an ever increasing investment in compiler technologies that translate these abstractions into efficient executables that provide the computer tasks that we set out to specify in the first place. It is ultimately this communication that offers their greatest benefit.

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

Lisp Fundamentals

NOTE: for all my non-computer friends and readers. If technical topics bother you or make you tense, perhaps todays post is not for you. If you are not given cold sweats when facing a new topic with the flavor of computers or programming, by all means please join me.

There are many things that Lisp, the programming language does right. It never ceases to amaze me and I am going to once again take a few minutes to discuss exactly what some of these things are and why they are so important.

Lisp was not originally conceived of as a programming language. It was invented by John Backus as a notation to enable discussion about Alonzo Church’s lambda calculus.

Lisp is characterized by the structure of its expressions, called forms. The simplest of these is the atom. An atom is a singular symbol or literal and represents a value. For instance, 42 is a numeric literal whose value is the number 42. Similarly, “Hello, world!” is a string literal that represents itself as its value. There are also symbols, which are strings of unquoted characters that are used as fundamental elements of Lisp. There are rules for how a valid symbol is form but for now it is sufficient to know that a symbol starts with a letter and then is composed of zero or more additional characters that can be either a letter, a number, or one of a collection of certain punctuation characters. Since the exact list of other characters varies among the dialects of Lisp, we will leave them unspecified at present.

The other type of form is a list. A list is comprised of a left parenthesis followed by zero or more forms and ending in a right parenthesis. Notice I said forms instead of symbols. The implication here is that you can have lists embedded in other lists as deeply nested as you like. This proves to be an interesting trait as we will soon see.

There is one more fundamentally interesting aspect of Lisp. That is that in a typical Lisp form the first element in a list after the left parenthesis is taken to be an operator. The subsequent elements in the list are considered arguments. The operator is either a function, a macro, or a special form. Macros and special forms, while extremely important and interesting are beyond the scope of this discussion.

That leaves us the operator as function. A typical Lisp function form is evaluated as follows. The first element is examined to determine what kind of form the list is. If it is a function, the rest of the arguments in the list are evaluated and collected in a list and the function is applied to them. If another list is encountered as one of the arguments, it is evaluated in exactly the same way.

For example, consider the expression (+ 4 (* 8 7) (/ (-26 8) 9)). The first operator is +. + is a symbol bound to the function that represents addition. The second item in the list is 4. It is a number that represents itself. The next element in the list is the list (* 8 7). When evaluated, the 8 and 7 are arguments to *, the multiplication function and the value returned by that function is 56. The final element in the top level list is (/ (- 26 8) 9). The / is taken as the division function and is applied to the evaluation of (- 26 8) which is the subtraction function that returns 18. When you divide 18 by 9. you get the value 2. Thus the top level argument list  consists of 4, 56, and 2. When you add all three of those numbers you get 62 which is the value that the expression ultimately returns.

This simple mathematical expression illustrates another fundamental aspect of Lisp. It is expressed as a list form which, given a set of bindings to arithmetic functions expresses a simple program. This identical representation of both data and programming in Lisp, called homoiconicity by the way, is at the heart of much of Lisp’s power. Since Lisp’s programs are indistinguishable from Lisp’s data, they can be manipulated by Lisp programs to great advantage.

Think of it like this. Lisp can, in some sense, think about how it is thinking and modify it as it desires. This is why artificial intelligence investigators like using Lisp so much, it is so similar to the simplified models of intelligence that they are building that the boundary begins to blur.

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

The Evolution of Computer Languages

I’ve got a thing about computer languages. I consider myself to be somewhat of a connoisseur. I have a soft spot in my heart for Lisp but I am also fans of other languages based on the context. I spent ten years more or less as an evangelist for Java. At the time I was fluent in Java, C, BASIC, and Pascal, I was conversant with Lisp, Scheme, Smalltalk, and Ada, and I could read most other languages but in particular COBOL, SNOBOL, Fortran, and Prolog.

While I personally preferred Lisp, I felt that the bulk of the programmers at the time were C or C++ programmers. As such, Lisp looked and behaved weirdly from their perspective. Java represented a huge movement in the right direction while remaining a language accessible to C programmers.

At the time, everybody was impressed by the elegance of Smalltalk and the object oriented, message passing paradigm. Smalltalk was also too esoteric for most C programmers but there was a guy named Doug Cox that came up with a language called Objective-C that captured some of the object oriented flavor of Smalltalk in a syntax that appealed to the C crowd. This was about the same time that Bjarne Stroustrup was experimenting with C++.

Both Objective-C and C++ proved to be overly complicated, especially when it came to managing the dynamic allocation of memory. Consequently, they both gained a reputation for being difficult if powerful. This was the state of affairs when James Gosling was faced with developing a language for a set top box. The requirements were that it be fast, easy to write bug free code in, and it would be well integrated with the network. And, of course, it would be object oriented and have automatic memory management in the guise of garbage collection. In short, Java was no Lisp but it was about as close to it as the programmers of the day could get their minds around

As it turns out, Java did raise the bar to the point that now, some twenty years later, it has itself passed into the conservative end of the spectrum and new languages now fill the spot it once held. In fact, Lisp has had a resurgence in popularity in recent years.

This renewed popularity can probably be best explained by the fact that Lisp has always been a research language. It was conceived as a notation for the discussion of Church’s lambda calculus but it’s simple, homoiconic syntax quickly became a powerful tool for creating derivative languages to explore new programming paradigms.

Consequently, concepts such as structured programming, functional programming, and object oriented programming had their first experimental implementations in Lisp. It has been said that every new feature in every new programming language introduced since Lisp was first created have been done first in Lisp and often better.

Which brings me around to a point of sorts. Since all of these languages have been gravitating toward Lisp for all these years, why hasn’t Lisp just taken over as the language of choice? There are a number of answers to that question, some of them contradictory.

For years Lisp had a reputation as being terrible for problems with a lot of mathematical computation. The truth of the matter was that the implementation of arithmetic in most of the Lisps of the time was good enough for the researchers that were primarily interested in investigating aspects other than numerical computation. When later generations of Lisp implementors took the time to optimize the numerical performance of Lisp it came to rival C and Fortran in both speed and accuracy.

This illustrates the important observation that Lisp has seldom been considered a language for the development of production software. A couple of blatant exceptions have been the use of Lisp in the development of software to predict the performance of stocks on Wall Street and software to predict the most likely places to explore for oil. These domains were willing to accept some rough edges in order to solve these particularly hard problems at all.

At one point it was argued that the automatic garbage collection of Lisp would kick in at the most inopportune time and embarrass the developer mid-demo. Advances in the technology of garbage collection have since made this argument mute.

Another often sited argument used against Lisp is the claim that other, more popular languages have a larger selection of third party libraries available to them than Lisp does. This does remain a challenge to some degree however many Lisp implementations have Foreign Function Interface mechanisms that allow them to call library routines written in other languages.

Another spin on the question is that Lisp has regained popularity especially in revised dialects like Clojure which has taken the opportunity to refactor the architecture of collection types so that the operations on them have similar names when they do similar things. This makes the language easier to learn. Clojure also runs on top of the Java Virtual Machine making interoperation with the vast Java third party libraries one of its attractive features.

The sad conclusion that I come to is that Lisp is a good source of inspiration and even a moderately good platform for investigation of architectural approaches to difficult, complex software systems but the benefits of the languages such as Racket, Swift, Ruby, Groovy, and even Javascript usually far outweigh any advantages that Lisp may once have had when it comes to implementing software for production use.

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

8 Bit Fantasies

I watched a video interview with the Oliver twins. They are video game legends from England. They started developing video games as teenagers in 1983. They went on to start their own game studio. In the interview, they talked about the process of developing games. They observed that the constraints of creating games for eight bit processors with limited display hardware often made it easier to creating games than the relatively unconstrained environment of modern hardware. The reason this is so is that when the hardware has severely limited capabilities it forces you to think backwards from the constraints to the design of a game.

The counter intuitive fact of game design is that games with simple rules and clear goals are more fun. For example, chess only has six unique types of pieces and is played on a board of 64 squares and yet the combinations of valid games is astronomical.

Another thing they commented on was the importance of thinking about the program with pencil and paper before they started writing code. They discovered this because when they started developing games they only had one computer between the two of them. Consequently, while one of them was entering code into the computer, the other was figuring out what they were going to tackle next when they got their turn on the computer.

Listening to them talk about their game developing experiences reminded me of a friend that I knew in the same era. Stan and I worked for Intergraph as computer technicians. We tested and repaired a specialized processor that allowed high speed searches for graphical elements in CAD files. In short, we both understood how computers worked in great detail. Stan owned an Atari 800 computer. We spent many hours talking about game design for the Atari.

As I think back on these conversations, I realize that the hard part was never implementing game ideas in code. It was coming up with simple yet engaging ideas for how the game would work. We didn’t spend enough time with pencil and paper. We both wanted to sit down and start coding immediately. This is an important point that needs to be taught when we teach people to code. A little bit of design up front can save a lot of trial and error programming later. And also, adding artificial constraints to the design process can have the surprising effect of making it easier to invent an interesting game.

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

The Making of a Programmer Part III

I worked at Intergraph for six years. When I started there it was a startup in the exponential growth phase. It was exhilarating to come to work every day. I was working on cutting edge technology. My first job at Intergraph was as a technician. I tested and repaired specialized computers that were optimized to search graphics files for patterns. My Army training had prepared me for just such a job.

I enjoyed my work for six months or so. Then I got tired of working with broken computers all the time. One of the engineers discovered that I knew how to program and gave me some tasks to do. Before I knew it, I was working for him and he was the head of the newly formed networking department.

I was given the task of writing a program to copy files from one computer to another over the network. Originally the plan was to write the program using Pascal, I high level, structured programming language. I was uncomfortable with that. I kept finding problems with the implementation of Pascal that would have to be worked around. I finally suggested that we implement the program in assembly language.

Programs on the PDP-11 were often given three letter names. I called my file transfer program IFM and told my boss it stood for Intergraph File Management. I told my friends the truth. It stood for It’s F%#$ing Magic.

After making IFM work between two PDP-11 computers my next challenge was to add VAX-11 computers to the mix, that is I had to transfer files from PDP-11 to VAXs, VAXs to PDP-11s,  and VAXs to VAXs. Luckily, VAX-11 assembly language was a super set of PDP-11 assembly so the translation went smoothly.

The next challenge came when Intergraph decided to build an intelligent desktop workstation that ran Unix. I was provided an early prototype of the workstation, serial number 8, to get file transfer working. This time the underlying file system was different than it was on the DEC machines. I had to start from scratch. I decided to use C, the system programming language made famous by the Unix system.

My new file transfer program was called FMU for File Management Utility. I leave it to the reader’s imagination what that actually stood for. C proved to be a powerful language and I learned to employ all kinds of heuristics to determine how to preserve the semantics of the files while transferring them from one type of file system to another.

It was during this time that I went back to college. I had over two years of credit under my belt and the college that I was attending didn’t have a Computer Science degree program at the time. So, I took Physics, and Calculus, and all the computer science classes that they offered. I ended up getting a Bachelors of Science degree in General Studies.

I worked full time while getting that degree. The last term before I graduated, the college announced that they were going to start offering a Computer Science degree. I asked what it would take to get a second degree in Computer Science. They looked at my transcript and said that all I would have to do would be to take forty more hours to establish residency and I would have the degree.

By this time I was friends with most of the professors in the Computer Science department. I arranged to teach one class and take two ever term until I finished my second degree. I taught Operating Systems a number of times, 8086 Assembly Language, and Artificial Intelligence. It was a great time, but all good things must come to an end.

One of the other colleges in the area had a bunch of Computer Science professors with PhDs that didn’t get tenure. The college that I was attending snapped them up and didn’t renew their contract with anoy of the adjunct professors with less than a PhD. I took my second Bachelors in Computer Science and called it a day.

Next installment I’ll talk about my experiences working on the Star Wars program, working for NASA, and landing my dream job at an AI lab.

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

The Making of a Programmer, Part II

When we left off I was talking about my experiences circa 1980. I had been writing Computer Aided Instruction (CAI) for the Army in BASIC. In particular, I was writing code for the Commodore Pet. It ran a particularly nice version of Microsoft BASIC, complete with support for both audio cassette storage and disk drives connected via the IEEE-488 GPIB interface standard.

Personal Computers of this era rarely had hard drives. The hard drives made developing software for the Pet relatively nice. It was while working there that I discovered that it was possible to write self modifying code on the Pet. That was, to my mind any way, a necessary, if not entirely sufficient, requisite for creating Artificial Intelligence.

During a Christmas leave we went home to Murphysboro, Illinois to visit my parents. My dad was a high school teacher and was negotiating the teacher’s salaries for the next school year. He had access to a Radio Shack TRS-80. I wrote a BASIC program that was essentially an early forerunner of a spread sheet to allow him to analyze the effect of salary adjustments on the overall cost of a given proposal. He could run two or three scenarios in the time that it took the school board to analyze one. I was proud of my impromptu hack.

After I got out of the Army, I went to work for a little company in Birmingham that specialized in selling personal computers to small businesses. They were particularly appreciative of my ability to go back and forth between building and troubleshooting hardware and writing software.

My big achievement there was a program that allowed a person with a blueprint of a sheet metal part to describe the part to the computer so that the computer could generate a paper tape to control the machine that automatically punch out the part. The paper tape was called a Numerical Control (or NC) tape. I called my program an NC Compiler. I had to write an assembly language driver to control the paper tape punch that was hooked up to the computer.

It is important to say that I wasn’t learning how to program in a vacuum. For my entire four years in the army and for years afterwards I subscribed to Byte magazine. Byte magazine was completely devoted to personal computer hardware and software. They published schematics of hardware, and listings of software. Every August the published their annual computer language special issue in which they featured a different computer language every year.

Byte is where I learned about Pascal, Lisp, Smalltalk, Forth, Modula 2, Ada, Prolog, and other languages that I don’t even remember off the top of my head. They also published reviews of the various personal computer hardware and software products. It was the only magazine that I had ever subscribed to that I read the advertising as diligently as I read the articles.

There were other computer magazines that were influential like Kilobaud, and Dr. Dobb’s but Byte was the best of the lot. I wonder how kids today learn about computers but then I remember that they have something that we didn’t. They have the internet. If you want to learn something about programming today you have your choice of articles, books, or even videos telling you how it’s done. For that matter, you have the complete back catalog of Byte magazine and Popular Electronics at your finger tips. Of course, they are a bit out dated now. The are interesting from a historical perspective I guess.

When I left the small startup in Birmingham they still owed me several months pay. I finally was able to negotiated a swap for some flaky computer hardware in lieu of the back wages that I had little hope of ever seeing. Subsequently, I spent many a frustrating hour investigating the operating system of the little computer by translating the numerical operation codes back to the assembly code mnemonics so that I could analyze them, a process called disassembly.

It was about this time that I decided to go back to college and finish my bachelor’s degree. In the next installment I will talk about the languages that I was learning, and some of my experiences working for Intergraph.

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

The Making of a Programmer

I sometimes think about the way that I learned about computers. I started out with a subscription to Popular Electronics magazine. At the time, I didn’t know much about electronics. I quickly learned about Ohm’s law which describes the behavior of electrical current in a resistive circuit. I picked up various details about other types of circuits and components by reading articles about them.

My dad’s cousin, Jim Shrewsbury had written an introductory book on radio. I read it cover to cover. I decided that I wanted to get an amateur radio license so I bought a copy of the ARRL Radio Handbook. I had trouble mastering morse code so I didn’t obtain a license until I was an adult. But I learned a lot about electronics.

In January 1975, Popular Electronics published the first installment of a two part article on building a small computer. Up until then, computers were large machines that took up lots of space and required lots of power. The idea of an individual owning one was rather novel. My imagination was sparked. I wanted one.

I read everything I could find about computers. I got access to a multi-user computer called Plato at the college library. When I was desperate for a job I enlisted in the Army for training in digital computer repair. After a struggle to pass basic training, I found myself in Huntsville, Alabama at Redstone Arsenal to learn how to fix the computers in the Pershing missile system.

The first part of the course taught us about digital logic, the basic building blocks of computers. Next, we learned about a small computer built specifically to teach how computers worked called the ComTran-10. I later learned that it was patterned closely after the Digital Equipment Corporation PDP-8 minicomputer. This was my first experience with writing assembly language programs for a computer.

Assembly language is the native language of a computer. It varies between computer models. Each assembly language instruction corresponds to an instruction that the central processing unit (CPU) of the computer executes natively. Once you’ve learned how to write programs in assembly language there is no program, in theory, that you can’t write.

That is of course a bold statement. It assumes that you can break down the problem into simple enough pieces that it can be expressed in assembly language. It also assumes that when you finish breaking down the problem, you have enough hardware resources, memory, CPU time, etc., to actually execute the program.

The way most modern programs are written are in higher level languages. Higher level languages are programs that translate programs from languages that are easier for humans to understand into the raw binary numbers that represent the assembly language instructions that the CPU can directly execute.

The process of translation is magical. The first higher level languages were written in assembly language. But then, the subsequent higher level languages could be written in the earlier higher level languages. In modern times, the only people that actually know assembly language are the people that design CPUs and the people that write higher level languages. (Even though the higher level languages are written in other higher level languages, the still have to generate assembly code as output.)

In the rest of the course, we studied the two computers that actually comprised the Pershing system, the guidance computer and the launch computer. We studied every component in the entire system. We learned to troubleshoot the system down to the individual component level. In the end, we knew how those computers worked.

When I got back to Redstone Arsenal from my tour in Germany, it was to spend the balance of my enlistment as an instructor in the school where I had learned about computers. By this time the Commodore Pet computer was being used to teach students about digital logic. The Pet was the forerunner of the famous Commodore 64 computer that many kids of a younger generation than me cut their computing teeth on. The Apple II and the Radio Shack TRS-80 were also on the market by then.

BASIC was the language that all of them were programmed in. It was the language that I used to become a journeyman programmer. It was exciting. It was more powerful than any language I’d programmed in before (with the possible exception of the Tutor language that the Plato system used). But for all that BASIC was an awful language. But it was the best thing that we had at that time.

That was a turning point in my career as a programmer and it will serve as a good stopping point in my story. In the next installment, I’ll give some examples of the kinds of programs that I wrote in BASIC and the languages that eventually replaced it.

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

Courting My Muse

Elizabeth Gilbert, author of Eat, Pray, Love, gave a TED talk about genius in which she told us how the ancient Greeks and Romans believed the creative process worked. They believed that the artist was given their great ideas by spirits, the Greeks called them daemons, the Romans called them geniuses. Her point was that the burden of responsibility for creating outstanding works of art was perhaps too much for fragile human psyches.

I feel like my best work is done when I am able to step aside and allow the piece to just flow from somewhere outside of me through me and out to the world. It is perhaps tinged with something of myself but its source is outside of myself. I don’t know how to make this happen. I just know that I have to sit down and write. If my daemon or genius is with me, I may write something wonderful. But if it isn’t, I will still write. I will hone my craft so that when my daemon is there, I will be ready.

And this is something that I can apply to my music and my other creative endeavors. You can’t just sit around and wait for your muse. You have to court her. You have to give her the channel through which creativity can flow. You have to hone the craft with which the inspiration will become manifest.

And you also need to revel in the genius of other artists. It is through that inspiration that you can learn to summon your own muse. That is why as a writer, you must read as well as write. As a musician, you must listen to music as well as play music. And, as a programmer, you must read programs and run them to appreciate their unique qualities.

As an artist we risk so much. We put so much of ourselves on the line when we bring our art to the world. We should only have to do our best and hone our craft and be present when the masterpiece arrives. We shouldn’t have to suffer for our art. That is a misconception best laid to rest.

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