Tag: programming

How I Find Flow

At the suggestion of a friend, I watched a TED talk called Mihaly Csikszentmihalyi: Flow, the secret to happiness | TED Talk …. I have read his book, Flow, and so the ideas presented in the talk weren’t new to me. What I was reminded of was the necessity of a high degree of challenge combined with a high degree of skill. As I pondered that it occurred to me that in so many of the cases of flow that I have read about or experienced myself, one of the key factors was a level of familiarity with ones tools that was so intuitive that you don’t consciously think about them.

Take writing for instance. I have developed my typing skills to the point where I don’t think about spelling words anymore. I just think the sentences that I intend to write and they appear on the page. It feels almost like magic.

Similarly, when I write a program, I build it a piece at a time. I prefer interpreted languages, like Lisp or Python, because I can experiment with them as I think about the problem. The IPython environment is especially good for that kind of development as it records every expression you enter and every response that it returns and labels it with an index number (see the screenshot below).

You can also step through the history by using the up-arrow and down-arrow keys. You can edit the expression and then execute it again. Typos are not nearly as frustrating when you don’t have to type in the entire expression again. Notice I refer to the previous output with the _ character. The line that starts with the prompt: In [2]:  computes the square of 42 ( _**2) .

There are many other useful features of IPython. I am still exploring them. The nice thing about them is that they are optional. You can learn about them a little bit at a time and they don’t get in your way if you don’t know about them. This helps you stay in flow by not distracting you.

There are other nifty tools to help you write Python code. I have been using one called Spyder that is a multi-pane Integrated Development Environment similar to Xcode, Eclipse, or Visual Studio, depending on your preference as a programmer. Each of these other IDEs have add on software that helps you develop Python.

I’ve wandered a bit away from the topic but the point that I am making is that before you can experience flow while doing a task, you have to be comfortable doing it. Pick a tool, learn it until it disappears. When you are creating, the tool should become invisible to you. Your focus should be on the code that you’re writing, not the tool that you are writing it with. Furthermore, you should be thinking about solving the problem, not how you get the language to do what you want. That takes a good bit of practice to achieve as well.

To round out my examples by noting another activity where I experience flow. When I’m playing guitar, I experience flow. Especially when I am trying to play a piece that I’ve never tried before. Or when I try to learn a new song on the mandolin. It challenges me and demands skills that I often have to learn to get into the zone. It’s worth it though.

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

Choosing a Programming Language

I have come to a realization today. Actually it has been gradually dawning on me but it came clearly into focus today. I consider myself somewhat of a connoisseur of programming languages. It started when I was first learning about computers. I read every issue of Byte magazine. But my favorite issue of Byte was always the August issue.

Every August Byte featured a different computer language. This is how I first learned about Lisp, Smalltalk, APL, Forth, C, and several others. The language issue always featured several articles that illustrated the breadth of each language and described the innovations that it brought to the table. Byte magazine eventually faded into the sunset but my hunger for new languages only grew.

I was on a quest to find the most eloquent computing language so that I could write beautiful programs. On my journey I learned a lot about design, organization, communication, methodologies, and process. I also learned to program. I slowly began to realize that although some languages were more eloquent and expressive than others there were other factors that were more important in choosing a programming language.

First, you want to pick a language that is widely used and has a strong community. This is important so that other people will be able to read your code and maintain it. It also ensures that there are a lot of community developed libraries to leverage when you are coding your application. It also means that there will be people around to help you figure out what you are doing wrong when you are at wits end.

Second, you want to pick a language that has a clear understanding of its philosophy. This usually happens when a language is shepherded by a “benevolent dictator for life” as Guido van Rossum, the creator of Python, calls himself. Another example of this is Ruby’s Yukihiro “Matz” Matsumoto. This kind of strong vision helps keep the language focused on solving problems in a particular fashion. The consistent flavor of a language is often more important than any other measure of technical quality.

Finally, pick a language that you like. If you are going to spend large chunks of time reading and writing code in a language, don’t choose one that frustrates you or causes you to have to struggle with it to solve your problem. There are way too many choices of language out there to spend any time at all being miserable.

When you find a language that is good enough, quit looking, at least for the time being. There will always be a newer, better language. These languages will take years, even decades to develop a community and the resultant libraries and infrastructure that make a language ecosystem great. Revisit your choice periodically. Don’t discount the investment that you make in the language that you have been using.

Of course you will often be told what language you must use, especially if you are working on a large project. In that case, cheer up. There are always ways you can improve the experience of using a language, if no other way than using a disciplined approach that lets you capitalize on your successes and minimize your struggling. And there is always the ultimate consolation of learning features to avoid in choosing future languages.

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

Keeping Your Focus on the Task at Hand

A friend of mine commented on the post about fiddling with formats that I wrote several days ago. He said that he just used HTML when he wanted to get a page to look the way he wanted. I understand that I always have that option but I view it kind of like I do writing a program.

When it comes right down to it, I can always write my programs in machine language. Then I can get the machine to do exactly what I want. Only I can’t really do that any more. The programs that I want to write have become too complicated for me to write them in machine language. It would make a task that I would spend an hour on in a high level language take days. And tasks that I might spend a week on in Python might take months to get right in machine language.

Not only is there the issue of sheer effort but there is also the fact that because it takes so long to solve a problem at all in machine language, I would be way less likely to spend the time on tweaking it and refining it than I would if it were written in a higher level language.

And finally, there is the heart of the matter. I’m not really looking for the most efficient solution, I’m looking for an adequate solution. I want to think about the problem domain not the intricacies of mapping the problem domain onto the bare metal of the computer. I like my abstractions, thank you.

What this means when it comes to the analogy with WordPress is concerned is that WordPress gives me a consistent layout and lets me concentrate on writing. I am as adept with HTML and CSS and jQuery and JavaScript and all the various mechanisms used to render the incredible web content that we have all come to take for granted. But developing web content that way is hard work. And when I sit down to write a blog post, I want to expend the bulk of my effort on writing.

Hence, I use WordPress. I could embed raw html to achieve my layout goals within WordPress. But then I would have to remember how I did it every time and I would, in all likeliness, not achieve the consistence of layout that I am striving for. I’d rather find a consistent solution that someone else has written that is 80% of what I’m looking for than to have to implement it myself.

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

There’s No Such Thing as Done

I used to think there was a right way and a wrong way to write a program. I found myself on a quest for the elusive right way to implement whatever program I was attempting to write. I wrote and rewrote the code. I read articles and books on techniques and disciplines. Nothing seemed to make programming any easier.

Slowly I began to suspect that maybe there was a continuum from good to bad and most programs fell somewhere in the middle. I hadn’t given up on the idea that there was an absolutely right way to do things and an absolutely wrong way. I just had plenty of evidence at hand that there were lots of ways that were neither absolutely right or absolutely wrong.

I don’t know why it took me so long but I have finally figured out that there are no absolutes. There are only criteria against which any given solution can be judged. The key fact that I had been missing was that there is almost never a single criteria by which a program can be judged.

I have become a dyed in the wool pragmatist. If a program achieves its intended purpose, it is good. If you discover there is another attribute that you would like it to exhibit, you have added a criteria. Now the program may fall short of adequately achieving its purpose. This will require some thought and perhaps a rewrite of the original program.

This activity of rewriting became so common that it has been given a name. It is called refactoring. Refactoring is done by first implementing a test suite that exercises the features that are implemented in the program as it is. It is also good to check the program in to a source code management system such as Git or Mercurial or even Subversion. There are plenty of others but these three are popular right now. With your test suite and backup copy of your original program you can now confidently start refactoring your program.

There are a number of ways that a program can be refactored. Each one solves a particular problem with the code as it is at present. For instance, you may have output to a particular type of output device hard coded in your program. In order to continue to support your current favorite device while setting the application up for supporting different kinds of output devices you might refactor your program so that it calls a print method on an output abstraction class. Initially you would concentrate on implementing an output abstraction class that supports outputting to you current favorite device. You aren’t going to want to quit using it.

When you have written that code and tested it against your existing test suite to ensure that you haven’t broken something in the process of changing the way it works, it is now time to implement the code to write to the new device. You will want to make sure that the current test suite still passes and that the code that supports the new device works properly. After that you need to write tests specific to your new code and ensure that it passes those new tests. When they work, check the new code and the new tests into your source code management system. You’ve implemented your new feature and you are ready to start on the next one.

Oh and don’t worry. Someone will want the program to do something more or differently before you know it. You have job security for as long as you want it.

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

Fiddling with Blog Formatting

WARNING: This post is primarily an experiment in how to format code in-line in a blog post. If you don’t understand this post, it’s probably because I’m doing a lousy job of explaining myself. I am concentrating on form instead of content. Tune in tomorrow and I’ll probably be back to making some kind of sense. And now, back to your regularly scheduled blog post, already in progress.

I found that there is a style pulldown in WordPress that lets me put preformatted source code in a blog post. Surprisingly enough, it is called ‘Preformatted’.  There is an example of how it looks in the box below.

def hello():
    print('Hello, world!')

if __name__ == '__main__':
    hello()

There are better looking ways to embed source code in a blog post but this is the simplest one. Some of the other ways provide syntax highlighting to make the keywords of the programming language stand out. Most of them provide line numbers to make it easier to talk about the various lines in the program. I will investigate those tools and report back on them as I learn how to use them.

Since I have a piece of Python code to talk about, I will attempt to explain what the program in the box above actually does. When loaded interactively into a Python interpreter, it defines a function called hello() that prints the string Hello,world! on the screen.

If the file containing this code is run from the command line, the variable name is given the value ‘main‘. The code after the if statement at the bottom of the box checks to see if name is equal to ‘main‘ and if so, the function hello() is called in the body of the if statement.

If the code is imported as a library, on the other hand, name will not be equal to ‘main‘, so the body of the if statement will not be executed. The code that imports the file can then call the hello() function at its own discretion.

If you know Python, this post has probably been boring. If you don’t know Python, it has probably been confusing. This post has been more of an exercise in how to format code in a blog post and less of an actual tutorial on Python.

If you are interested in a tutorial on Python, look here. I will probably write more about Python in the future. I will make the code prettier next time. I will make the prose more illuminating. But there is just so much time available to blog each night and I didn’t have time to experiment with formatting and write riveting content in the same post.

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

Fibonacci Fun with Python

I’ve been playing with numbers with Python. I wrote a function that returns the nth Fibonacci number. Fibonacci numbers are generated by taking zero and one as the first two numbers, then adding the previous two Fibonacci numbers together to yield the next one. The next Fibonacci number after 0 and 1 is also 1 since 0+1=1. The next one is 2. The next one is 3. The next one is 5. And so on. Strictly speaking, the first Fibonacci number is 1 since there is another trait that Fibonacci numbers exhibit and 0 can play no part in that. Given two successive Fibonacci numbers, the ratio of the greater to the lesser of the two will tend toward the golden mean or phi.

The golden mean is approximately 1.61803398875 although, like pi, it is an irrational quantity that has no exact expression. It can be written as the expression (1 + square_root(5))/2. It is the square_root(5) term that makes the number irrational. But, if you will notice, 1/1 is 1, 2/1 is 2, 3/2 is 1.5, 5/3 is approximately 1.667 and as you continue to compute the ratio with larger and larger Fibonacci numbers, the result gets closer and closer to phi.

Phi is an interesting quantity. It shows up in many places in nature. Some of the claims about it, for instance that it is evident in the logarithmic curve formed by a Nautilus shell, have been disproven by empirical study. Others, like the fact that the ratio of the length of a diagonal of a regular pentagon to the length of one of its sides is phi, are on sound footing. In any case, computing Fibonacci numbers and phi can be an interesting pastime.

I found a simple function in Python that yields the nth Fibonacci number in relatively short order without having the unfortunate side effect of consuming the entire stack.


def fib(n):
a,b = 0, 1
for x in xrange(n):
a,b = b, a+b
return a

view raw

gistfile1.txt

hosted with ❤ by GitHub

This function takes an integer argument n. It initially sets a to 0 and b to 1. Python allows you to set multiple values with one assignment statement as shown in line 2 above. Then, for  a variable x assigned to every value between 0 and n-1, which is to say n times, you set a to b and b to (a+b). When you are done, you return a because it will be the nth Fibonacci number.

I learned several things while writing this blog post. First, when you are computing Fibonacci numbers, the values get large very fast. For example, the 100th Fibonacci number is 21 digits long. The 1000th Fibonacci number is 209 digits long. Another thing I learned is that the square root symbol does not render as such in a standard web page. I am somewhat baffled by that as it renders fine in the WordPress editor. Perhaps I will discover a way around this.

I also learned how to use GitHub to create a gist, that short block of code above. A gist allows you to display the program formatted as it would be in a code editor instead of formatted as prose as it would be if typed directly into the blog post.

I learned other things tonight but I don’t intend to belabor this post with a lengthy explanation of everything I learned. Perhaps another night.

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

Python For The Win

Today I remembered what I love about programming. It’s that feeling that you get when you know what you want to accomplish. You have an idea of how to start realizing your vision. You are comfortable with your tools, that is the language and the editor that you are using to write your opus. With these elements in place you are set to experience flow. Flow is a state of mind, studied and characterized by Mihály Csíkszentmihályi, where the task at hand is difficult enough to be engaging but not so difficult that you get stuck trying to accomplish it. As you finish one task, the next one becomes apparent to you. It is an exhilarating feeling.

What happened today is that I found a Python package called openpyxl that allows you to read and write Excel files from Python. This was the solution that I was looking for to my problem with analyzing large data sets stored in an Excel spreadsheet. I had been struggling to do it with VBA (Visual Basic for Applications) but I found it to be difficult to use. I found plenty written on it but nothing that spoke to my problem domain. If anything, there were too many mediocre books targeted at spreadsheet power users that were novice programmers. I am the opposite, a casual spreadsheet user that is an expert programmer.

I figured out after I thought about it for a while that experienced programmers just weren’t going to put up with a language as shabby as VBA. Not only was it a bad language but it had no standard definition and was proprietary to Microsoft. Consequently, it was subject to Microsoft’s favorite ploy of making radical changes to the behavior of the language from one version of the product to the next. It made no sense to me to invest any significant amount of effort into crafting a solution only to have to entirely redo it at the next release of Excel.

To summarize, I made more progress today than I would have in a week with VBA. And as a bonus benefit, my code is readable to the large and ever growing cadre of Python programmers. It was a brilliant idea and I’m still floating on air over having figured it out.

Basic was a good first cut at a first language but we have learned a lot about how computer languages should work since it was first released in 1964. Bill Gates and Paul Allen started Microsoft with Microsoft Basic in 1975 and it was a clever implementation that made the limited resources of the early personal computers more approachable by total computer novices. In the intervening 42 years, we have developed a number of languages that fill the niche that Basic originally targeted much better.

Python has become very popular for both casual scripting and implementation of large projects. It has the inertia associated with a large user community and a responsive team of implementors. There is a clear definition of the language and a carefully controlled process governing the evolution of the language. I can develop in it with confidence that my work won’t be rendered obsolete by the next release of the language.

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