I've written many times before about my trial runs of various Linux distributions and I feel like I've said most of what I have to say about the matter. However, I recently saw a post entitled, Is Ubuntu Useable Enough For My Girlfriend? and I decided to have one more go at explaining my ambivalent feelings towards Linux.
First, a brief summary of the post for the link-impaired; relatively experienced Linux user sets up his girlfriend (Windows user, not super technical) with an install of the latest version of Ubuntu, gives her a set of mundane tasks (watch a YouTube video, Google something, do some photo editing) to achieve while he takes notes and hilarity ensues.
I tend to cringe when highly technical users try to predict what a non-technical user will find easy or difficult; there is just so much background knowledge that someone who is passionate about computers takes for granted, that I think we are uniquely ill suited for the task. So, I try to rely more on colloquial evidence, such as this post.
His girlfriend is able to accomplish many of the tasks, but is stymied by a few, mostly due to poor naming or lack of clear instructions on how to install the necessary application or plug in. The conclusion is that Ubuntu is heading in the right direction, but is still not ideal for your "average" non-power user.
This line of argument has been around since Linux on the desktop became a reality, so at first glance it can seem old, stale, whiny or just plain obvious. If you get beyond that initial reaction, it is an amazing commentary on the state of Linux on the desktop. How is it possible that so many talented individuals have labored so long and yet still been unable to produce a desktop system on which these type of basic tasks are as straightforward as they are on Windows or Mac?
I'll answer that question with another question; could you see Ubuntu declaring a one year new feature freeze, refusing any new graphical bells and whistles, new processor extensions or file system upgrades and instead focusing the next release of Ubuntu entirely on making it as simple as possible for non-technical users to accomplish simple general computing tasks? Imagine the brain power of that many talented contributors all working just towards usability. I think you'd have your killer desktop in way under that one year timeline.
However, my question is flawed. What is Ubuntu? There is an organization around it for sure, but it is not a monolithic one that can give orders to the entire Linux development community. Also, while usability is a stated goal of Ubuntu, it is not necessarily a goal that is shared by many of the elite programmers in the Linux development community. Or more accurately stated, many elite Linux developers are quite comfortable in Linux and don't feel excited about spending time making it "easier".
Quite to the contrary, many technical people are attracted to Linux due to the rapid pace of technological advancement. So in essence, you'd be asking the very people who innovated so much to get Linux to where it is now to stop innovating and focus on the unglamorous task of noob babysitting. Or as the author of the post puts it, "The main issue with the desktop experience is that the geeky programmers and designers assume too much from the average user."
In fairness there are plenty of developers who buck this stereotype and pour effort into usability. Otherwise we wouldn't have distros like Ubuntu at all. Recognizing the good work that the Ubuntu (and other distros such as PCLinuxOS and Xandros) have done with usability, what's left to explain the persistent gap?
I think the often overlooked part of this discussion is that Windows and Mac (OS X) set the norms. Whether or not it is fair or just, most people are exposed first and most often to Windows or OS X and from that initial experience, their expectations are set for how interacting with a computer should take place.
This behavior can be maddening and seem foolish, but is not surprising, at least as explained as Dan Ariely describes in his book Predictably Irrational. Ariely calls this type of behavior "anchoring" and anchoring can explain such oddities as how black pearls suddenly became sought after (they were once relatively unknown and then were introduced first only in high end jewelry stores for high end prices) and how we can feel like we are getting a great deal on a car when we buy it for significantly below the MSRP, despite the MSRP being a somewhat arbitrary number.
So, to come back on topic, even if desktop Linux were easier to use based on some kind of scientific figuring, as long as it remains close enough to our anchor ideal of computer interaction without quite being the same, it will seem inferior and less desirable.
The baseline has to be that either desktop Linux does at least everything as easily as Windows/OS X does plus more or that it presents such a different and satisfying experience that a new anchor is established. A concrete example of this is the iPhone; by offering such a tightly knit and innovative take on the interface of a cell phone it was able to define a new standard for what cell phone UI's should be.
There is movement within the Linux community to develop new desktop interface experiences such as Symphony One and mainstream distros using KDE and Gnome are inching ever closer to matching the out of the box Windows/OS X experience while still offering the power and variety that make Linux fascinating. I am not sure which approach if either will ultimately win out because the final elephant in the room is that Microsoft and Apple are not just standing still, they are trying to take the best bits they see from their competitors and improve their own products.
After 2 months of dormancy, I am starting back up the easy way, with some short notes on topics of interest:
1. Windows Home Server: 2 Months In
The best compliment I can give is that I just don’t think about my Home Server anymore. I let it do its thing and don’t worry about it. I am anxiously awaiting the Power Pack 1 additions, along with the data corruption bug fix (which has not affected me at all yet). In hindsight, I should have just gotten a prebuilt solution, avoided the install pain and had a machine with a smaller footprint, but my custom build does get the job done.
2. Microsoft OneNote: Better than TXT?
I’m still using OneNote at home to take notes on Core Python Programming (my current Python resource of choice), but at work I’m back to using mostly NotePad2 and other plain text editors. Even though OneNote does not fight you as much as Word, it still has the annoying AutoCorrect behaviors that sometimes make plain old text much less of a hassle. The feature to publish your notes to a web page format is nice, although Microsoft’s decision to use the obscure .MHT format is confusing. So after a few months of use, my opinion of OneNote is far more mixed.
3. Netflix Impresses
One of my favorite new technology toys is Netflix “Watch Instantly” feature. The quality is very good, and although the available content is mostly TV shows, seeing what you want, streaming, when you want it, is really an amazingly satisfying experience. If Netflix can integrate this into a set top box, watch out.
4. Indexed
I was going to draw a clever graph showing the inverse relationship between work load and my blogging frequency, but it seemed too obvious, so I’ll just plug the real Indexed site, which is far cleverer. I have been exploring the Python web framework Django, so work load non-withstanding, I hope to share the rare sight of some code on this blog in the near future.
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.
Back in the pre-Facebook era, there was a certain political figure who has accused of suddenly dressing in earth tones on the request of an advisor who thought that these muted colors were reassuring to audiences. This plan, especially after it was revealed, did not have the desired effect.
However, code is by nature easier to dress up than a person. And with the .NET Parallel Extensions, released as an add-on to the 3.5 .NET Framework as a CTP in December, Microsoft is attempting to take the edge off of threads by clothing them in an extra layer of reassuringly subdued abstraction.
This weekend, I attended a session of the SoCal Rock & Roll Code Camp at Cal State Fullerton about these newly released extensions. The presenter, Rinat Shagisultanov, gave a quick overview of what was in the extensions, as well as some working examples. There is a lot in there, so check it out yourself for all the details, but what really stuck out to me was a point Rinat made early in the session. To paraphrase, his point was that Microsoft already gave us the Framework with its threading capabilities and this extension did not change this, rather it gave us some nice building blocks on top of the existing Framework to make writing the code less intimidating.
The curious might ask, like what? The most basic example would be the addition of the Parallel.ForEach construct , which can be used to quickly transform a strictly sequential execution path into a parallel one. This construct gets a little more complicated when you are actively working with shared state, but the basic idea is that the Parallel Extensions spins out a thread for each core and distributes the work between the cores without you having to write the plumbing code. There is also PLINQ (Parallel LINQ) for querying objects in parallel, as well as the Task, Future and TaskManager objects which allow for finer grained control of the distribution of items of work in parallel. (1)
I won't get any further into the details of the API's at this point (although perhaps I will in a later post) because I want to return to the idea these extensions are really less intimated or earth toned threads. Threads could use the help, as they are pretty universally regarded as one of those "hard" topics in programming.
Lots of programmers cringe when they see code in an application that starts spinning out threads. They begin to imagine the nightmares of debugging seemingly random errors and designing the appropriate access schemes for shared memory. It is somewhat a badge of honor to brave the depths of multi-threading and come out with an application that is reasonably stable.
If threads are to be one of the prime mechanisms for parallelism and the importance of parallelism is increasing with multi-core machines, isn't it bad that they are perceived to be so difficult and obtuse? One answer to that question is that they are not really all that hard and most programmers are just stupid. I call this the unintentionally dismissive guru stance; once you've figured something out, you cannot really remember how hard it was for you to do it.
Another answer is that they are hard, but that's OK, because threads are too powerful and dangerous for the average programmer. This is the intentionally dismissive grizzled vet stance; you've earned your stripes working on multi-threaded applications and you don't need some newbie bumbler coming along and fouling things up.
The answer that Microsoft has given with the Parallel Extensions is yes, threads hard and yes that's a problem, so here's some tools that give you a chance to get the parallelism you want (using threads under the covers), but only dive as deep into the intricacies of the threads as you absolutely have to. I call this the populist approach; give something to the masses (even if it's not perfect), at the possible expense of being looked down upon by the elite.
I have not gotten a chance to dig deep into the Parallel Extensions yet, but apparently it is due to be incorporated into the next base distribution of the Framework and what I have seen looks really promising. These extensions, especially when you deal with shared state, will still open up some dangerous traps for the unwary, but they lower the bar for entry and provide some nice base abstractions to work with. In fact, coupled with WCF services, you can see the outline of a .NET grid computing architecture with multi-threaded services distributed across multiple machines pretty easily out of the box. (2) So do yourself a favor and add this CTP to your long list of new parts of the .NET Framework to learn.
(1) Rinat gave a more comprehensive breakdown of what these different API's are and what they could be used for, so any confusion you may experience in reading my description is of my own doing. The slides and code he presented in the session are on his blog at: Code Camp, Fullerton, CA Jan 2008: Concurrent Programming in .NET (Parallel FX)
(2) Some would actually argue that you should not really use multi-threading paradigms anywhere for concurrency; everything should be based on message passing between processes and thereby avoid the problems of accessing shared memory. That is an argument I am not prepared to take on, but for a strong version of the pro-argument see the language Erlang, which is built around the principles of no-shared memory, processes and message passing.
Careful readers of this blog have probably noticed that despite working for a company that specializes in custom software development using Microsoft technologies, I have not posted much about Microsoft or .NET technologies. Instead I have focused on general software development topics, plus a smattering of exploration into non-Microsoft languages, such as Python, Ruby and Erlang.
Python, Ruby and Erlang have all been wonderful to learn about and work with, and I continue to plug away at all of them in various capacities. General topics, such as my last post about versatilists and technicians are fun ways to provoke some debate. And in general, I haven't found there to be a dearth of .NET related blogs to comb through.
Nevertheless, I wanted to venture back into the crowd to talk about what I think .NET does right (despite being too popular and widely used to ever be called "sexy"). Put simply, what .NET does right is to shift the focus away from particular language features and to the environment that the developer works within.
Let's put some meat on those bones. What I'm suggesting is that Microsoft has put a lot of effort into taking away any excuse a developer has for not creating a successful application by surrounding this developer with a vast array of supporting tools.
The first of these tools is the .NET Framework itself, an embodiment of the "batteries included" philosophy, which is composed of a giant number of classes designed to make your life easier as a developer. Than there is Visual Studio, oft criticized for its bulk, which provides you with IntelliSense (to find you way through that big framework), a web designer and a forms designer (to easily create GUI's), an nicely integrated debugger, and with some editions, a profiler, nicely integrated source control, etc. Then there is the documentation, represented officially by MSDN, which is expansive and nicely uniform. Finally, there is the community, which owing to the popularity of .NET is somewhat a self sustaining advantage in that so many people are using .NET and writing about it that a well phrased Google search is a .NET programmer's best friend.
So, as a .NET developer, a lot of the job of programming is done for you. This does not mean that developing applications in .NET is easy or for dummies. It just means that the challenges of programming in .NET usually arise not from algorithm design or harnessing obscure language features, but in finding, understanding and customizing the right set of components and tools for your particular application.
In fairness, this approach is not unique to .NET, but the .NET ecosystems size and structure puts this approach to the front and center. And like all generalizations, this one is not entirely accurate as there is a lot of creative effort being put into the .NET languages themselves. Nevertheless, I think it is accurate to state that .NET is distinguished just by how it is described, as .NET, a full environment for developing applications, not just a specific language.
Joel Spolsky had an excellent post discussing his views on restructuring CS programs in colleges to be more attractive to potential students and produce better programmers. His Bachelor of Fine Arts in Programming curriculum includes more project and software lifecycle work, plus some liberal arts classes, minus some of the more advanced theoretical topics typical to CS programs.
I love the sound of this program as I really enjoyed a similar program at my college where I took liberal arts electives and got to do a decent amount of project work my senior year (and a lot of it in a part time job during my junior and senior years). I did have to take some of the more advanced theory classes and learned from them, just not too much that I've had to apply in my everyday work.
Joel got on this topic by referencing an article in Crosstalk, the Journal of Defense Software Engineering which is revealingly titled Computer Science Education: Where Are the Software Engineers of Tomorrow?
I would sum up the article as follows: the writers use the programming language Ada for projects (presumably military related) where security and reliability are paramount. Large frameworks and external libraries are mostly useless to them in this environment. They cannot find as many recently graduated computer scientists as they would like to fill these jobs because the type of programming involved is very math intensive and low level. What is to blame for this shortage of qualified individuals?
... Java has become the most widely used language in introductory programming courses. We consider this to be a misguided attempt to make programming more fun, perhaps in reaction to the drop in CS enrollments that followed the dot-com bust.
... The result is a student who knows how to put a simple program together, but does not know how to program.
So, the authors make the opposite recommendation of Joel and suggest that CS curricula be modified to include more theory, more math, a lot of C and of course some Ada if possible.
Which one is more persuasive? Actually, they are arguing past each other. They disagree on the fundamental purpose of a CS degree. Joel wants a graduate to have a wide breadth of problem solving skills, including non-technical ones and project experience, and the Crosstalk authors would like a graduate to have a well defined and deep set of technical skills. Or to put it more simply, the argument is about whether a CS major should be a technician or a versatilist.
As a consultant for a company that takes on a wide variety of types of problems, I come down on the versatilist side of the equation. From a popularity standpoint (i.e. attracting students to a major), I also think the versatilist style as embodied by a BFA in Programming is attractive to more students than an even more technically oriented program. However, when it comes down to it, there is no substitute for good technical skills and we'll always need good technicians.
I think Joel is a little loose in his terminology in saying that:
When I said BFA, Bachelor of Fine Arts, I meant it: software development is an art, and the existing Computer Science education, where you're expected to learn a few things about NP completeness and Quicksort is singularly inadequate to training students how to develop software.
While I may not find it too appealing, the projects that the Crosstalk authors refer to definitely involve software development and I can see why they want people with absolutely excellent technical depth to develop systems for the harsh conditions of a military environment. So, I don't expect the standard CS curricula to disappear any time soon, but I hope colleges follow Joel's advice to start offering more versatilist programs to live side by side with the traditional, offering students interested in programming plenty of ways to explore that interest.
Happy New Year! As 2008 starts up, I took a brief look back over what I blogged about in 2007. From music services (still a happy eMusic customer) to Python to Erlang to Apple to lots of operating systems, I covered a diverse swath of the computing world.
While reminiscing about the past year, I identified what I think drew my interest to these topics. As a developer, I am naturally looking for the next best thing in programming languages. As O'Reilly put it in the title of a recent book, I am on the prowl for 'Beautiful Code'. As a consultant, I am looking for the best solutions for my clients. Since we mostly develop custom software applications, I am looking for 'Beautiful Applications'.
'Beautiful Code' is about algorithmic excellence and syntactical elegance. 'Beautiful Applications' are about providing great user experiences that solve the problem at hand. Often we don't have visibility behind the curtain to know if these two go hand in hand, but intuitively we expect that they should.
It is my suspicion that this intuition is wrong and is in fact a deceptive simplification; that since we've all had experience writing code for an application, we mistake this one part of an application for the whole of it. However, a simplification is not the same thing as a falsehood; code obviously has a huge effect on our applications. So while this past year I spent a lot of time looking at beautiful code and beautiful applications separately, hopefully in 2008 I can concentrate a little bit more on exploring the interplay between the two.
One of the givens of web programming is that there are a lot of different web frameworks out there to choose from. With this many choices, it is also a given that there is a lot of competition amongst these alternatives; which is better, faster, more scalable, easier to learn, easier to modify, etc.
Beyond technical discussions, for which a Google search will find more than enough flame wars to keep you busy, there is the marketing/branding, which is easy enough to show you with these screenshots of the home pages of some of the web frameworks out there.
Scan through these screenshots and try to identify how each of these frameworks is selling itself. Notice any common patterns? If you've used any of these frameworks, is this how you would describe it? Does the site peak your interest in the framework? Does the design of the page make you comfortable that this framework will help you produce your own sites that look great?
Opinions will vary, but the site that really jumps out at me is the Ruby on Rails site, which immediately grabs my attention with a non-standard page layout, forceful "this is different and that's good" branding and the inviting "Get Excited", "Get Started", "Get Better" and "Get Involved" links.
ASP.NET
Ruby on Rails
Django (Python)
TurboGears (Python)
ErlyWeb (Erlang)
Erlang (a language not a framework, but honorable mention for "retro" 1990's style)
(gOS Desktop)
In my previous post I mentioned gOS, a customized version of Ubuntu that is the default OS on the low cost gPC from Walmart. The initial supply of these PCs quickly sold out and gOS itself has been getting some good reviews, such as the this one from Linux.com. After spending some time with it inside a virtual machine, I also had a generally positive impression. I won't try to compete with the depth of the numerous reviews you can google for yourself, but I did want to explain why I put an image of a toaster at the end of my last post.
A toaster is a ubiquitous appliance; its functionality is well defined and most people can easily figure out how to use one. The question is whether or not a computer can me made more like a toaster, with circumscribed functionality, but enhanced usability. gOS is a step in that direction. Under the hood it is actually based on the full featured Ubuntu Linux, however, it is designed and marketed to be used in a limited fashion.
If a user of gOS never had to go beyond the predefined shortcuts from the lower menu bar, then I think the makers of gOS would be satisfied with their work. And based on just these shortcuts, a user could browse the web, do email, IM, manage their iPod, connect to social networking sites, etc. All of which taken together offer a nice package of activities for that mythical average computer user.
And, to echo other reviewers, gOS largely succeeds in this offering; if you were to buy a $200 gPC and really stayed within the predefined activities of gOS, you would be pretty happy. I will be interested to see if the popularity of the gPC continues, and if it does, if other vendors jump into the mix. Of course, there is already one vendor out there that tries to provide you with an easy to use, integrated out of the box, task based approach to computing. It's just that their starting price point is $599, leaving some room for competition from below.
Over Thanksgiving, I had the task of setting up of a new PC for my mother-in-law over the holidays, a task which I was happy to do, but gave me another chance to get up close with Vista. At home, I have reverted to running XP, for reasons which I discussed in the last post of this series.
I had higher expectations for this new machine as my plan was to basically set it and forget it, since it will mostly be a web-browsing, email and photo machine. Sure enough, when I kept my tinkering to a minimum, I was rewarded with a much smoother experience. This was also helped by the lack of pre-installed trial/adware on this new Dell Vostro.
The only bumps along the road were the old printer not working, which is more Lexmark's fault than Vista's and the typical UAC behavior of asking me to confirm twice the heinous act of renaming a desktop shortcut. Then there was Windows Update, which after helpfully updating the Word/Excel Viewers, also helpfully set them to be the default file handlers for those types. A nice gesture, although it ignored the fact that I had set Open Office to be the default.
So beyond the fear that the next auto update from Windows Update will knock out the file associations, I have a tenuous hope that this PC will be able to perform the basic tasks of email, web browsing, light photo editing, office document editing, printing and scanning, with a minimum of maintenance.
These are modest expectations for a modern computer. Recently I have been seeing more attempts to make computers like appliances, with limited functionality, but increased reliability. For me, being a computer enthusiast, it is the general and not limited nature of computers that make them so interesting. However, for the majority of those who probably don't really care about the details as long as they can complete task x, y and z, an appliance approach could make sense.
I'll see how Vista fares in this role, but in the meantime, I fired up the old virtual machine and have been testing out gOS, the Ubuntu derivative installed on the low cost gPC from Walmart. Look for my impressions, an overview of its functionality and a possible explanation for the following clip art in the next installment of "OS Chasing".
In his blog, author Jonah Lehrer relates the story of several experiments run around wine tasting. One experiment involved coloring a white wine red, the other involved putting the same wine in two different bottles. In both experiments, expectations overrode the reality of the wines. So the same wine in the more expensive bottle tasted better and the white wine that was colored red tasted like a red wine.
In his post, The Subjectivity of Wine, Lehrer presents the argument that the exterior factors, the context of an object and our expectations towards it, have just as much influence on our perception of that object as its inherent qualities:
As the philosopher Donald Davidson argued, it is ultimately impossible to distinguish between a subjective contribution to knowledge that comes from our selves (what he calls our "scheme") and an objective contribution that comes from the outside world ("the content").
Lehrer's post may make you feel better if you ever felt snubbed at a wine tasting by a know it all, but it also has important implications for software development. The context of a piece of software can matter just as much as its content. Meaning that there is an explanation behind the common complaint you hear from developers than that an "inferior" product is displacing their preferred and technically superior one.
Defining the context of a piece of software is tricky. The user interface is so inherent to software that it isn't really fair to call it the context. A more valid definition of the context of software would focus on the soft factors around it. Is the producer of the software seen as a reputable and reliable vendor? Was the software coded by senior developers or junior interns? Is it free or does it cost money? Is it a much anticipated upgrade or a forced one?
A lot of these questions are good ones to ask. Since most of us don't have the time or access to evaluate the software we use at the code level, it is a useful mental short-cut to feel more comfortable about a product coming from someone you trust (since they have a proven track record) or a product you paid a lot for (surely they would not be able to get away with charging a lot for something that wasn't good). Like all short-cuts though this approach is not full proof. There are innumerable examples of the free products that are superior to their commercial ones. Not everything from Apple will help harness your creativity, etc.
Of course a product that fails utterly at its purpose will not be able to disguise its flaws from its users. However, it is worthwhile to note that part of the experience of using a piece of software is how you feel about it; how you feel about the software depends not only on functionality, but on the context of it. So, if you have spent the time it takes to make a quality technical solution, take some extra time to think about how you can put that solution into the most favorable context. Having the best code isn't always enough.
More Posts
Next page »