February 2008 - Posts
If you use Outlook, Word and Excel frequently, there is a good chance you actually have the entire Microsoft Office suite, which includes some well known applications, like PowerPoint and some not so well known ones, such as Microsoft's OneNote. OneNote has been around since 2003 (the year and MS Office version), but I only started using it when I installed Office 2007.
OneNote is, as the name suggests, primarily a note taking application. Free form pages are organized by the note taker into notebooks. Notes are not just text, they can be images, links, sounds and videos. Notes and notebooks can be published as PDF documents and shared with other OneNote users. This may not sound like the most exciting application, but I've found it to be a surprisingly effective way to keep information organized.
I use OneNote (in addition to a paper journal) to organize ideas and research for blog posts. I use it at home with my dual monitor setup to take notes while watching screencasts and working my way through programming books. At work, I'm experimenting with using it to organize the many small notes to myself I make about projects that usually end up on notepads and then in the recycling bin.
OneNote's interface features tabs across the top for notebook sections, with tabs down the side for pages within the notebook, making it natural and quick to create a nested structure for the information. OneNote also includes its own screenshot tool to facilitate capturing snaps into notes.
Finally, when I open up OneNote it doesn't come with the heavy mental baggage that Word does. I've used Word for years and years, so when I open it up, I think of essays, reports, specs; pretty much all more formal documents. OneNote encourages me to be informal, which is what these notes should be. OneNote also fights against me far less often than Word does; so far I've yet to encounter the frustrating Word behavior where Word just won't let you type in anything until you adjust your formatting.
Long time readers of this blog will remember that I once discussed my somewhat unique diet of more, but smaller meals during the day. The book that explained this relies heavily on sports analogies, one of which is the "undervalued prospect", used in the book to highlight certain foods which lacked the reputation for being healthy, but were actually great things to have in your diet. I think the undervalued prospect is a good analogy for OneNote's place within Office. I never really see it get hyped, but if you take the time to get to know it, OneNote has a lot to offer.
Recently Google Docs added a Forms feature to their spreadsheets. This feature allows you to generate a form that can be filled out via email or on a page hosted by Google. The submission of this form then populates the data back into your Google spreadsheet where the responses can be collated online or exported as an Excel spreadsheet.
I think I just made that sound more confusing and difficult than it is; it takes under a minute to set up, and you can see my "Ice Cream" sample form by following this link: http://spreadsheets.google.com/viewform?key=p4Wm_X_NqY4oWmEuN8g25YA.
This functionality has a lot of potential and is a great tool for creating small and simple surveys. It exists in a similar space to Microsoft's InfoPath, but is much simpler and being Google, free. Speaking for lazy developers (is there any other type?), it is certainly not a bad thing to let non-technical users create and manage these kind of forms and save the technical users' efforts for more complex tasks. Or trying to speak from the non-technical users perspective, this is great since you can accomplish these seemingly simple data collection tasks without dealing with any irritable tech folks. [1]
[1] Note: As a software consultant I am obligated to point out that we never fit into this "irritable tech folks" category :)
Following the recommendation of my co-worker Mike Frank, I decided to give Windows Home Server (WHS) a try. WHS has the capability to do a lot of different things, but straight out of the box I was looking to take advantage of its automated backup capabilities, data duplication, file sharing and remote access capabilities.
I have only had WHS installed for a few days, but my first impressions are very positive. I don't know what I expected, but it just works. After I got it installed, setting up the connector software on my machine was easy and I was immediately setup for nightly backups. File sharing was also quick to setup and after a few well explained configuration changes to my router, I had a web site up so I could access my shared files and computers from anywhere with an internet connection. There is a lot more I want to do, including exploring Xbox 360 integration, putting a source control server on it and installing some of the many user created plug-ins, in particular for media management.
On the install side, I did run into some trouble. I built my own system, which is not the route that most consumers would probably take as there are a lot of solid looking pre-built options out there. I did some research beforehand to find parts that were compatible, but still had a problem getting my SATA hard drives recognized.
The first part of the install went smoothly, but then there is a part of the install that looks like it uses the Windows XP text based installer which does not have built in drivers for SATA drives. So, I was confronted with having to do the F6 "provide additional drivers" step, which means I had to have drivers on a floppy disk.
Since I have built a fair number of systems, I have a floppy drive (which sadly is still an essential tool for a system builder). However, I didn't have any other computers around that I could install the drive on to load a floppy disk with the SATA controller drivers. The motherboard came with a CD of the drivers, so I could take the drivers off there to make a floppy, but I needed a machine I could boot into to do the copying. So kind of a chicken and egg problem since the server machine was not in a bootable state.
My solution was to reboot the server off of the install media for WHS and then pretend to load additional drivers in the first GUI based part of the installer. This part of the installer uses standard Windows file dialogs to let you search for additional drivers. Standard Windows file dialogs let you right click, copy and paste files, so I used this dialog to navigate to the drivers (on a USB key) and then copied and pasted them to the floppy disk which I had hooked up to the server. I then canceled out of that dialog, got back to the text installer and was ready for the F6 to floppy disk, which worked perfectly. So, that was annoying and more time consuming than I care to admit, but beyond that the install was straight forward. I will wait until I've had the server up and running for a while before I give WHS a full review though.
Because making programs short is what high level languages are for. It may not be 100% accurate to say the power of a programming language is in inverse proportion to the length of programs written in it, but it's damned close.
Paul Graham, "Take the Arc Challenge"
By definition, there is some optimal path from axioms up to a complete language. The Platonic form of Lisp is somewhere inside the block of marble. All we have to do is chip away till we get at it.
Paul Graham, "First Priority: Core Language"
Paul Graham, Lisp guru, founder of the startup company incubator Y Combinator and essayist, has always been somewhat of a lightening rod for controversy. He is highly opinionated and has a wonderfully concise and direct style of writing that does not back away from confrontation. So it was not too surprising to see the relish with which his detractors have criticized Arc, the language he invented, since an early alpha version was released recently.
Arc is a dialect of Lisp, with a focus on "exploratory programming" or rapid prototyping. A distinguishing feature of Arc is that it was/is built from the ground up with a focus on terse syntax that leads to short programs. As the first quote in this post illustrates, Graham believes that power is inversely proportional to program length. Program length is not equal to character counts necessarily, rather it is based on the size of the tree you'd need to represent the program. So, the first example from Arc is a program that displays a web form with an input field that parrots back what you type in when you submit it:
(defop said req
(aform [w/link (pr "you said: " (arg _ "foo"))
(pr "click here")]
(input "foo")
(submit)))
This example has 23 nodes according to Graham's counting technique and he challenges anybody to produce a shorter program using a different language.
I'm sure there will be no lack of responses to this challenge, but I find the whole premise to be flawed. The idea that a language inherently has a measurable amount of "power" in the first place is suspect. Having power means to possess controlling influence. In the case of a programming language what would it have influence over? The answer could be loosely summed up as the domain of the problem.
To be more specific, if you are writing a telecommunications system, Erlang would be a very powerful language as it grew out of that domain; however, if you were creating a rich client side UI, you might use C++ or C# with WPF. Because programming languages are used to solve such a wide swatch of problems, it is impossible to have one controlling definition of power. Power for a programming language is completely dependent on context.
The contra-argument to this is that I'm describing the libraries of languages, not their core syntax, structures and features. I would argue that you cannot evaluate a language outside of its libraries; even the definition of libraries is difficult, as in the case of Arc where a "core" language feature is a construct for creating web forms. This might be called a library in another language, but if that language decided to incorporate that library into the core, then would that language suddenly become more powerful?
To be fair let's say we ignore the problems with using the term power and accept the premise that certain languages will in general make a programmer more able to solve the problems they encounter. Graham's premise is that brevity is the key to achieving this competitive advantage.
Why would brevity be such an advantage? Less boilerplate/setup code, fewer things for the programmer to keep in their mind; these are what I could think of. I don't find either of those reasons all that compelling. Certainly attractive and nice to have, but not enough of a reason to ditch one language for another. Unfortunately, Graham seems to find the idea pretty much self evident and does not offer much in the way of supporting evidence.
Since Graham is obviously a smart guy, I got to thinking about why he would be so sure that brevity is the key component in designing a powerful language. I looked back at the example of Arc and was struck by the similarities to Shoes, a domain specific language in Ruby for creating GUI's. I spent some time creating an extremely primitive flash card program in Shoes and really enjoyed it. Here's an example of the syntax to create a simple application with a button and an attached click event:
Shoes.app {
button("Press Me") { alert("You pressed me") }
}
So Arc and Shoes possess similar compact syntax and Arc's aform construct looks like a DSL for creating web apps. Pushing the comparison further, Shoes is written in Ruby, a language strongly inclined to produce DSLs, which was strongly inspired by Lisp. And here we come full circle to what I think is the core of Graham's argument.
Graham's affection for Lisp is well known; Arc is a dialect of Lisp and he explicitly states (as shown in the quote above) that he set out to design Arc with the goal of creating the true and pure (or Platonic) Lisp.
So when Graham is saying that succinctness equals power, he is not saying anything he hasn't said before. This is really another front in the long running argument between Lispers and advocates of other languages, where Lisp, for a laundry list of reasons (including the power of macros to make short programs), is held up by its advocates as the one true language and by its detractors as a jumbled mess of parentheses and arcane incantations.
So Graham's Law of Power could perhaps more clearly be stated as the power of a programming language is directly proportional to its "Lispness." Or the more vulgar form that every other successful programming language is really just a poor implementation of Lisp.[1]
[1] I disagree with that argument, but if you are interested in hearing more, allocate a few hours and a couple of Google searches and you will find more than enough material from both sides to keep you busy.
Fred Brooks' seminal work, The Mythical Man Month, is rightly considered a classic on the topic of software development. Although it was originally written over 30 years ago, it is still a remarkably insightful and interesting read today.
The apparent timelessness of Brooks' work is surely due to its focus on managing and improving the software development life cycle, not on specific language techniques. Brooks' anticipates some of the tenants of extreme programming by suggesting rapid prototyping, extensive use of test cases and continuous customer interaction. He is optimistic about the benefits of object oriented development despite some initial reservations to the idea of keeping the code within components hidden from plain view.
He discusses the difficulties of estimation, the utility of keeping a project workbook (kind of a proto-wiki) and suggests a "surgical" team structure to maximize productivity. And of course, he presents and later defends the so-called "Brooks' Law", that adding people to a project that is late will only make it more late.
In the epilogue to the 20th anniversary edition of The Mythical Man Month, Brooks discusses how it has become impossible to keep up with all the new developments within the software industry:
The computer related intellectual discipline has exploded as has the technology... Today my intellectual life has seen me regretfully kissing subdiscipline interests goodbye one by one, as my portfolio has continuously overflowed beyond mastery. Too many interests, too many exciting opportunities for learning, research, and thought. What a marvelous predicament!
While marvelous, this is a predicament and as such, begs a solution. Brooks' hints at one when he discusses the difference between the essence and the accidental in software development in the chapter, "No Silver Bullet". Briefly stated, the essence of software development is the modeling or description of a problem into the software realm, while the accidental is the actual implementation of the essence (or specification) into working code. Brooks' estimates that 90% of the effort in a project is the essence. And yet we spend a lot of time trying to maximize the 10% of the accidental.
Based on this ratio, if object oriented programming can streamline the 90% of the essence by providing a good conceptual framework to plan a product around, then it is a worthwhile addition; however, writing a program using an object oriented language without following object oriented concepts is not in and of itself an advantage.
Let's return now to our marvelous predicament. It is almost tautological at this point that one developer cannot possibly master all their is to know within the field. Yet, most developers are by nature are very curious (a point Brooks makes early on) and so they will want to keep learning new things. So some selection criteria must be used to winnow the available choices. Looking to Brooks, a good criteria might be to concentrate on learning new things that let you more effectively attack the essence of software development, not the accidental.