Nick Mudge

After Apple and Microsoft's ad campaigns, "I'm a Mac" and "I'm a PC", the Linux foundation is now holding a video contest for "I'm Linux". Check out the press release.

A little while ago a friend asked me what kind of programming I was interested in. I ended up explaining the difference between system programming and application programming:

In application programming programmers build applications. Application programs include websites, video games, iPhone applications, Microsoft Word, Microsoft Excel, Web browsers and other programs that people use for entertainment, communications, accessing information, organizing, and getting work done. Application software interacts with people or users.

Systems programming is creating technology that programmers use to build applications. In order for an applications programmer to build an application, he needs an operating system, a programming language, and other tools to get the application built, tested, and working.

System programming includes creating and working on:

• operating systems
• database systems
• programming languages
• software libraries
• software that controls hardware very directly

Software exists in layers.
Application software runs on top of and interacts with system software.
System software runs on top of and interacts with the physical hardware.

Another way of looking at it:
People make application software do work.
Application software makes system software do work.
System software makes the physical machine do work.

I kind of realized for myself how to debug software. The bug will be at the very end of where a program is working correctly. So one merely needs to test the execution of code from the beginning of execution going forward until one finds an error. I've often said, "follow the logic". By this I mean test or examine the code from the beginning of execution until you find the error.

So this is how a person could debug:
Find the very start of execution of the code. Test the execution of the code from the beginning going forward. One could test the beginning of the execution, and then a little more of the execution, and a little more of the execution, until an error occurs. Before you give up trying to find an error, throw out all your guesses and assumptions and test everything.

A faster way to find an error when you have no idea where it is, could be like this:
Find the midway point of the code that executes. Test the first half of the executing code all at once by only running or testing this first half of the code. If no error occurs, then the error doesn't lie or manifest in the first half of the code.

Now you have the second half of code. Cut the second half of the code in half. Now test the first half of this code. If this code works, then you know the error lies in the second half. So cut this second half in half and test this first half and so on. The whole idea is to zero in on the bug by eliminating code that you know works. When you find a code half that doesn't work, then cut that half in half and test the first half and so on until you find the exact bug.

This halving of code method is the same idea of the best way to guess a number out of 100. You guess 50 and someone tells you if the number is higher or lower than that. If the number is higher, then you guess 75, if the number is lower, then you guess 25. You continue cutting the numbers in half until you get the right number. If you were guessing a number out of a million, it would only take you 20 or less guesses to get the right number every time.

The best method I have found of finding a bug is to eliminate working code so that all that is left is the bug. And the bug will be at the very end of working code. The skill and imagination of locating a bug in this way is figuring out how to cut your code in half and get your code reporting to you the right kind of errors. In my experience, there have always been ways of getting code to report to you errors.

This method of locating a bug is also a good method of finding a bottleneck when there is a performance problem. Time the first half of code and then second half of code. Take the slower half of code and cut it in half and time those halves to find the slower half and so on.

Zune
Many Zune mp3 players froze on December 31 because the software wasn't programmed to take in account the extra day in 2008 due to it being a leap year. The players began working the next day on 1 January 2009.
http://news.bbc.co.uk/2/hi/technology/7807797.stm

Year 2038 Problem
I've been thinking about the Year 2038 Problem recently. This is when the time software on Unix and Linux and many software goes haywire. Time is stored as a signed number of seconds since January 1, 1970 and the number is stored in 4 bytes which means that the number can only go as high as 2,147,483,647. In 2038 this number will be reached and will wrap around to becoming all zeros and all the software that uses this will record time as if it was 1970 again. This will become a problem much sooner than 2038 though because future times are often used in calculations, like peoples 30 year mortgages. I wonder if some money could be made fixing this problem for people.
http://en.wikipedia.org/wiki/Year_2038_problem

Real World Haskell
The book "Real World Haskell" was released recently. What is significant about it is that most or all books on the Haskell programming language have been very academic and not written for industry and many practical uses. This book is written for the "Real World", like many other practical books for programming languages that are widely used. And of course Haskell itself is one of the most interesting programming languages in existence, I think. Here's the book online: http://book.realworldhaskell.org/read/ You'll notice that people can leave comments on each paragraph. The authors developed this system to get continual feedback from users as they wrote the book - this is sure different.

Why and Potion
I've recently become fascinated with a guy that calls himself, "Why the Lucky Stiff", who has been active in the Ruby community, and who just recently released a new programming language called "Potion". It's a "little fast language", about 4,000 lines of code.
Potion: http://github.com/why/potion/tree/master
Wikipedia Why entry: http://en.wikipedia.org/wiki/Why_the_lucky_stiff

Javascript Games
I'm impressed by the games that can be programmed in the browser with javascript: 25 Amazing JavaScript Games

Guido van Rossum, creator of Python, is writing some great stuff about the design, basic principles, history and summary information about Python.

Here's some links:
Python's Design Philosophy
A Bird's Eye View of Python
The History of Python - Introduction
Scala?

I haven't written a blog post in awhile. Just wanted to drop a note that I'm alive and kicking. I'm around. I'm spending my blog writing time rewriting my blog sofware. I have a busy schedule, but I'll be getting my new blog done and I'll be blogging a lot more.