Category: computers

Another Sip from the Firehose, Please

There is so much to learn. Every time you start to do something, no matter how simple it sounds, there are always so many things you don’t know about how to do. You get to the point where you aren’t overwhelmed by this fact. At least not most of the time. I managed to diagnose my computer problem. I was about to lose my hard drive. I was able to replace the hard drive with another that I had. It is a little bit smaller than the one I replaced but it is big enough to hold me for a while. I am going to have to buy an external drive so that I can do regular backups. It has taken me the better part of eight hours to figure out what needed to be done and get it done.

Back to the topic at hand, it isn’t just with technical subjects that this happens, although they do seem to offer a lot of fodder for befuddlement. I run into the same problem when it comes to cooking or playing the guitar. Just listening to music on Pandora sends me to Wikipedia to look up the new bands that I’ve discovered to see how it could have possibly taken me this long to hear of them.

I remember my dad used to say that getting a Ph.D. was all about learning how little you knew about anything. Maybe the same thing applies to life in general only it seems like it takes longer to realize it if you don’t go through the pressure cooker of academia. It seems to me that I have been going through a process lately that parallels that which I watched my dad go through when he got his doctorate. I’m not saying it’s the exact same thing but I have noticed some similarities.

Now that I’ve got a working computer again, I’ll set up the writing software and get back to writing my book. Maybe it will be less frustrating now that I have a machine that I can count on.

Wring every bit of enjoyment from life. Tell the people you love that you love them. And most important, be kind.

Another One Bites the Dust

As if enough hadn’t gone wrong already lately, I got up this morning and my computer told me there were important system updates, so I installed them. When it finished updating, it rebooted. Only when it did, it had a fatal error on reboot. I would have expected as much out of Windows but this was a Linux machine. I didn’t have time to troubleshoot it so I booted the Windows partition and was able to read my email, record my vital signs, and write my morning journal entry (different from my blog). I had to fight off the requests to update my windows installation but I  was able to get what I needed to do done.

When I got home this evening, I booted Linux from the install disk and was able to backup my files. I am writing this blog post as my Linux home directory is copied over to an SD card. When that finishes, I’m going to see if I can repair the current installation. If not, I’ll reformat these partitions and start again from scratch. I need to buy a couple of external disk drives so that I won’t be stuck in this situation again.

I know that hearing my tale of woe about my computer problems is hardly satisfying fare for a blog post but I promise to do better tomorrow. I refuse to let a little thing like a computer malfunction get me down. Sleep well and have pleasant dreams. Tomorrow will be another day, resplendent in all of its glory. Enjoy your fleeting time upon this Earth and above all, be kind.

 

A Brief Survey of Dynamic Programming Languages

A lot has been written about static languages lately. I am going to focus on dynamic languages. Dynamic languages allow the programmer to develop software by interacting with a “live” language system. The system accepts input and gives feedback about that input immediately as it is entered and evaluated. This encourages an experimental approach to programming. What happens when I do this? Just do it and find out immediately.

I talked at some length about the oldest dynamic language, Lisp, last time. As such, it provides an example of many of the features of subsequent languages. It is classified as a multi-paradigm language. This means that it supports many different styles of programming. You have probably heard of object-oriented programming. Lisp has a very flexible object system called CLOS (Common Lisp Object System). You may have heard of functional programming. Without going into great detail about the details of what functional programming is, Lisp was one of the first languages to treat functions as directly manipulable elements. Lisp also supports rule-based programming, aspect oriented programming, and many other programming paradigms. It has been said that most new languages are just adding features that were pioneered by Lisp.

What other dynamic languages are there? Another venerable and influential dynamic language is Smalltalk. It was developed by researchers at Xerox’s Palo Alto Research Center (PARC). It was the first language to treat every element in the langage as an object. It also was a complete system including editors, code browsers, and a host of other tools, all written in Smalltalk. The system is programmed by interactively defining new objects that are immediately available for use as soon as they are defined. The entire system is graphically oriented. Many of the concepts of modern graphical systems were first introduced by Smalltalk. Unsurprisingly, there are a number of implementations of Smalltalk in use today.

Another dynamic language that has been around for a long time is Forth. Forth is another language that inspires strong opinions. Programmers either love it or hate it. It has been described as write only. It is based on the idea of using a temporary data structure called the stack to temporarily store operands to be used in subsequent computations. The stack is a mechanism where the programmer can “push” values onto the stack and later “pop” the last item pushed. All operations are done on the latest item pushed. This allows an arbitrary number of temporary values to be readily accessible. It also requires the programmer to keep track of exactly what has been pushed onto the stack at any point in the execution of their program. Hence, the “write only” label.

Forth allows the programmer to define new functions interactively through the use of a REPL (Read, Eval, Print, Loop). This is a key feature of dynamic languages and goes a long way toward making up for the cognitive load of keeping track of the contents of the stack.

One of the more recent dynamic language to gain popularity is Ruby. Ruby was inspired by Lisp but adopts the Smalltalk stance that everything is an object. It first gained widespread notice because of a popular web framework written in Ruby called Ruby on Rails. Many of the best practices of modern programming have originated in the Ruby community.

The last dynamic language that I’m going to talk about in this post has had a rather profound impact on computing in the last couple of years. I’m talking of course about Python. Python is an interesting language. Noted for the use of indentation to indicate the start and end of computing blocks and the ease of using code libraries written in other static languages, it has captured the hearts of scientists and educators alike. It is the lingua franca of the popular inexpensive computer the Raspberry Pi. It has carved out a place for itself as probably the most popular modern dynamic language.

In future posts, I’ll talk more about each of these languages and even show some examples of what programs written in them looks like.

Static Vs. Dynamic Computer Languages

I’ve talked about the history of computer languages some in previous blog posts. In particular, I’ve talked about the difference between compiled languages and interpreted languages. Now I’d like to make a further distinction. Some languages are static and others are dynamic. More specifically, static languages are reduced to executable instructions ahead of time during a compilation phase where dynamic languages are processed interactively as the programmer explores the solution space defined by her program.

Static languages can more easily be made to run fast and can more readily be analyzed for correctness. Dynamic languages support organic exploration of the problem and its solution. Dynamic languages can, and have, been made to run fast and analyze themselves for correctness. It’s just typically more difficult to do so.

The surprising thing, to me anyway, is that we have had examples of both kinds of languages pretty much since the first higher level languages were written. FORTRAN was a static language written for engineers to automate the solution of numeric problems. Lisp was a dynamic language to explore the potential for computers to do things other than just numeric computation.

Engineers and Managers liked FORTRAN and its descendants. The applications that were written in them were immediately practical and it was easy to measure how much work the programmers had done. Initially this was measured in Source Lines Of Code or SLOCs. This was all well and good until the programmers realized that a more complicated solution requiring more source lines made them look better to the managers that were measuring their performance.

Over time, we learned a lot about how to write programs in static languages until finally, in recent years, most “serious” programming is done in static languages like C++ and Java. This is a sad situation. Static languages are good for many things but there are a lot of problems that are better served by dynamic languages.

Lisp has a bad reputation among many engineers including many computer scientists. This is often because they were forced to write a project using Lisp in a Computer Languages course by an instructor that didn’t understand Lisp themself. But, to be fair, Lisp does require a little bit of a different mind set from most static languages.

There are also a bunch of myths about Lisp that may have had some basis in fact at one point but over time, Lisp has improved and the hardware that all languages run on have improved, and the myths are, for the most part no longer valid. For instance, it was initially said that Lisp wasn’t any good for doing numerical computing. That was initially true, largely because the authors of Lisp language systems were interested in exploring the non-numerical aspects of programming and consequently made little effort to make the language handle numbers efficiently. This was remedied in the early seventies but Lisp retains a reputation for being bad with numbers in some circles.

The main thing that Lisp is better at than its static conterparts is allowing the programmer to interactively explore a problem space. In a static language, one typically has to write a substantial amount of code before you get to the point where you can run it and see how it behaves. If it doesn’t do what you intend, which is typical for the first couple of attempts, you have to go back to the source and change it, recompile the program, and rerun it to see if you’ve fixed the problem.

With Lisp, one types expressions directly to the interpreter using what is called a Read Eval Print Loop or REPL. The REPL reads a line of code, interprets it and prints the resulting value. Then it repeats the process (hence the Loop). This allows the programmer to explore the problem and potential solutions interactively, getting feedback from the computer after each line. It is amazing how much faster correct programs are developed using this approach.

I’ll talk more about dynamic languages in another post soon. There is much that I want to say about them. And Lisp may have been the first dynamic language but it certainly wasn’t the last. I’ll have more to say about other members of the dynamic language family. I’ll also have something to say about ways that we can realize the best aspects of both of these styles of language by combining them into hybrid languages.

Professional Principles

I’ve been watching a lot of videos of presentations given by Brett Victor. This particular video was particularly inspiring. It helped me understand something about myself and my relationship with my work that I hadn’t been able to put my finger on before now. I realize that you may not have an hour to spend watching this video right now. If not, please consider bookmarking it and having a look at it later. I’ll try to give you a few clues as to why you might want to do that.

In this talk, Brett talks a lot about having a guiding principle that motivates  his work. Most of us just go to work and do the best we can to produce the work that is assigned to us. This is a valuable way to live your life but it leaves people like me unsatisfied. I want to create things. I want to discover new things that haven’t ever been discovered before. I want to change the way we do things for the better. This entails a lot more thinking and introspecting than just showing up and doing the work that is assigned to us the same way that it has been done by everyone else that has done it before.

Brett talks about his principle and gives examples of how he has modified the tools he uses to comply with his principle. He also gives an example of another person’s principle and how he worked to apply it and ended up changing the face of modern computing. I have a  yearning to do this kind of work. I’ve got a lot of introspection to do in order to figure out what the principle is that I want to champion.

Watch the video. Brett is much more eloquent than I am in explaining what he means and that will help you to understand my ramblings here a little bit better.

Memories of the Early Days of Microcomputers

When I first became interested in computers I was in high school. Most computers were expensive. Digital Equipment Corporation had just started supplying college laboratories with digital logic that was affordable for building dedicated digital lab equipment. My uncle Kell worked in such a lab building hardware to support experiments. I remember browsing through the DEC catalogs and handbooks when I would visit him.

Then, soon after I graduated from high school, Popular Electronics published a two part article on how to build a microcomputer called the Altair 8800. A small company in Arizona was selling a kit of parts along with a printed circuit board and a cabinet. The Altair had toggle switches for entering ones and zeros and lamps for displaying binary values. I had no idea of how to program but I wanted one.

Soon, there were many single board microcomputers, many fully assembled. There was the Kim I and the COSMAC Elf. These computers sported calculator style keypads and seven segment numeric displays. They also had interface chips that allowed them to be hooked up to teletypes or the new terminals that were initially called glass teletypes. And I wanted one of each.

Then there was a period characterized by computers with built in keyboards that produced video signals that could be fed to a regular television using an adapter that converted the video signal into a TV signal. The Apple II and the Ohio Scientific C1P were examples of these. I owned a C1P for a short while.

A little bit later, Commodore came out with the Commodore Pet computer that had a built in display and a built in cassette tape recorder to store programs on. I worked on a Pet writing Computer Assisted Instruction while I was in the Army.

Another computer or this era was the Radio Shack TRS-80. I wrote a program for my father on one that he borrowed from the school where he taught. The program computed a salary schedule based on a matrix that ran years of experience along the X axis and level of education along the Y axis. There were three of these matrices, one contained the number of individuals in each category, one contained the salary for each category, and the third contained the amount that each category would cost. I then summed all the cells of the last matrix to compute how much that salary schedule would cost. He was able to successfully negotiate a substantial raise for the teachers in his district using the program. This was before VisiCalc was invented.

I’ll write more about the evolution of small computers in a future post.