This is a test of how one might embed photos from Picasa's web albums into one's blog.
Monday, October 30, 2006
Thursday, October 26, 2006
OOPSLA 2006: Day 3, Thursday, October 26
Today I attended a tutorial on Python, a talk, and some papers.
The best part of the day, by far, was the talk by Martin Rinard from MIT. He described an experiment in what he deemed "Failure Oblivious" programming. The standard approach for dealing with discovered errors in code is that programs should fail early obviously when they run into an error. He described an experiment that took the opposite approach: instead of having programs fail early, have them not fail at all.
His group took several open-source programs with known errors and changed memory allocation and pointer schemes so that they could not fail. If the system tried to read outside of an array boundary, it would just return a manufactured value. If it tried to write outside of the boundary, it would just not write.
The result was that the programs did not fail. They would hiccup on the input data that ran across the error, but they would then chug along just fine after that. Rinard's contention is that, for many contexts, this is far preferable behavior to the current practice of throwing exceptions and killing the application. For one, people use very small percentages of the features of most programs. Often the user would prefer to keep using the other features in an application even if one of them starts giving them trouble.
I would very much like to do some more reading on this area. It would be fun to do some experimentation with this approach.
The best part of the day, by far, was the talk by Martin Rinard from MIT. He described an experiment in what he deemed "Failure Oblivious" programming. The standard approach for dealing with discovered errors in code is that programs should fail early obviously when they run into an error. He described an experiment that took the opposite approach: instead of having programs fail early, have them not fail at all.
His group took several open-source programs with known errors and changed memory allocation and pointer schemes so that they could not fail. If the system tried to read outside of an array boundary, it would just return a manufactured value. If it tried to write outside of the boundary, it would just not write.
The result was that the programs did not fail. They would hiccup on the input data that ran across the error, but they would then chug along just fine after that. Rinard's contention is that, for many contexts, this is far preferable behavior to the current practice of throwing exceptions and killing the application. For one, people use very small percentages of the features of most programs. Often the user would prefer to keep using the other features in an application even if one of them starts giving them trouble.
I would very much like to do some more reading on this area. It would be fun to do some experimentation with this approach.
Wednesday, October 25, 2006
OOPSLA 2006: Day 2, Wednesday, October 25
Today I went to a keynote address, a product demo, then a half-day tutorial.
The Keynote: By Guy Steele, gave an overview of a new language that he and his team are developing at Sun. The language is named "Fortress" and focuses on parallelism, and extensibility. Some years ago, he gave a keynote at OOPSLA advocating the position that languages must be grown gradually since they have become too complex to designed completely up front. Fortress approaches this by making the language itself fairly low-level in some ways, with much of the functionality (like a lot of the type system) that is normally part of the compiler actually part of the libraries. Programmers will be able to provide libraries that enhance operators and types, as well as provide alternative implementation of standard library functions.
Another really interesting aspect of this language is that there are facilities in the language itself for keeping track of components and versions of components in use. It sounds like some sort of SCM system built-in.
The tutorial: A kick-start for "Ruby on Rails". It was fun to actually do some programming this week after spending several days now listening to how other people have been developing software.
The Keynote: By Guy Steele, gave an overview of a new language that he and his team are developing at Sun. The language is named "Fortress" and focuses on parallelism, and extensibility. Some years ago, he gave a keynote at OOPSLA advocating the position that languages must be grown gradually since they have become too complex to designed completely up front. Fortress approaches this by making the language itself fairly low-level in some ways, with much of the functionality (like a lot of the type system) that is normally part of the compiler actually part of the libraries. Programmers will be able to provide libraries that enhance operators and types, as well as provide alternative implementation of standard library functions.
Another really interesting aspect of this language is that there are facilities in the language itself for keeping track of components and versions of components in use. It sounds like some sort of SCM system built-in.
The tutorial: A kick-start for "Ruby on Rails". It was fun to actually do some programming this week after spending several days now listening to how other people have been developing software.
Tuesday, October 24, 2006
OOPSLA 2006: Day 1, Tuesday, October 24
It was a full day. Here's the rundown:
After morning Mass, played a couple of games of chess at Starbucks.
Wandered through some of the book displays and posters.
Demo: Bringing Ownership Domains to Mainstream Java
Method to annotate object elements to ensure, among other things, consistency regarding encapsulations.
Demo: WebTest
Tool for testing web applications. This looks like a really impressive open-source web testing tool. You can check it out here.
Demo: Enhancements to refactoring tools in Eclipse
A project to make it easier to perform some refactorings in Eclipse. It did provide me with an immediately useful tip: In Eclipse, you can quickly build up a selection by hitting Shift-Alt-Up. If you start with the cursor on a word, it is selected. Hit Shift-Alt-Up, and the expression is selected. Hit it again, and the statement. Again, the block. Again, the enclosing block, working all the way up to the file itself. Very cool.
Took the train into Downtown for lunch.
I also went to presentations of three research papers:
It is amazing what a difference a presentation makes. I had glanced through some of these papers beforehand, but the presentation was really required in order to make sense of the context in which these techniques would be useful.
The final event I attended was an experimental art-thingy. It was good, because my brain was basically full. Each of us was given a large piece of paper and some pens. We were the told we would be listening to 43 minute of music by The Necks. As we listened, we were to draw a continuous line with our pens and basically let the music direct what appeared on the page. Our drawing was then filmed. The director of the project will make a time-lapse video of the drawings from several sessions like this and then show it Thursday evening. The music was interesting to a degree, but definitely from the "art should hurt" school.
Drove around, did a little shopping, came back to the hotel and watched the World Series game 3 while eating dinner.
After morning Mass, played a couple of games of chess at Starbucks.
Wandered through some of the book displays and posters.
Demo: Bringing Ownership Domains to Mainstream Java
Method to annotate object elements to ensure, among other things, consistency regarding encapsulations.
Demo: WebTest
Tool for testing web applications. This looks like a really impressive open-source web testing tool. You can check it out here.
Demo: Enhancements to refactoring tools in Eclipse
A project to make it easier to perform some refactorings in Eclipse. It did provide me with an immediately useful tip: In Eclipse, you can quickly build up a selection by hitting Shift-Alt-Up. If you start with the cursor on a word, it is selected. Hit Shift-Alt-Up, and the expression is selected. Hit it again, and the statement. Again, the block. Again, the enclosing block, working all the way up to the file itself. Very cool.
Took the train into Downtown for lunch.
I also went to presentations of three research papers:
- Research Paper: Pluggable Type Systems
- Research Paper: Design fragments Make using Frameworks Easier
- Research paper: JTL - Java Tools Language. Language used to help search Java code, even within Java.
It is amazing what a difference a presentation makes. I had glanced through some of these papers beforehand, but the presentation was really required in order to make sense of the context in which these techniques would be useful.
The final event I attended was an experimental art-thingy. It was good, because my brain was basically full. Each of us was given a large piece of paper and some pens. We were the told we would be listening to 43 minute of music by The Necks. As we listened, we were to draw a continuous line with our pens and basically let the music direct what appeared on the page. Our drawing was then filmed. The director of the project will make a time-lapse video of the drawings from several sessions like this and then show it Thursday evening. The music was interesting to a degree, but definitely from the "art should hurt" school.
Drove around, did a little shopping, came back to the hotel and watched the World Series game 3 while eating dinner.
Monday, October 23, 2006
OOPSLA 2006: Day -1, Monday, October 23
Went to two tutorials today. The first was on code generation. It was mildly interesting, but probably could have been about half as long.
The second was on an extension to the Java language called "X10". It is meant to help Java application developers take advantages of massively-parallel system. It was extremely interesting and could have been twice as long. (Ok, I would have gotten fatigued if it was twice as long. But they had enough good material to have a second session if they had so wished.)
The second was on an extension to the Java language called "X10". It is meant to help Java application developers take advantages of massively-parallel system. It was extremely interesting and could have been twice as long. (Ok, I would have gotten fatigued if it was twice as long. But they had enough good material to have a second session if they had so wished.)
Sunday, October 22, 2006
OOPSLA 2006: Day -2, Sunday, October 22
DesignFest
Today was a full day session of DesignFest at OOPSLA. We worked as a group of four designers plus a moderator. We tackled the basic design for a system to keep track of the ratings of players at a racquetball club.
It was an interesting problem, and team members came at it from several different directions. One profitable, although somewhat painful, exercise came from the fact that we could not agree on the basics of part of the design. So, we ended up doing three version of the design, looking at the sequence of calls for one of the main use cases. This was a rather intense experience, and somewhat draining. But it did really illustrate the value of being willing to take a design down to some detail, then backtrack, start again, and see where a different design will take you. Until you do that, you may have an intuitive idea of what will and wont work, but it won't be firm. After you do this, the strengths and weaknesses of the different designs are much more concrete.
Not really knowing what to expect, I had expected that there might be more of a component of either explicit mentoring or competition involved in DesignFest. I had hoped that a really senior person could critique what we did. But DesignFest really was simply an opportunity to get together with a group of strangers and work for a day on the design of a program.
Today was a full day session of DesignFest at OOPSLA. We worked as a group of four designers plus a moderator. We tackled the basic design for a system to keep track of the ratings of players at a racquetball club.
It was an interesting problem, and team members came at it from several different directions. One profitable, although somewhat painful, exercise came from the fact that we could not agree on the basics of part of the design. So, we ended up doing three version of the design, looking at the sequence of calls for one of the main use cases. This was a rather intense experience, and somewhat draining. But it did really illustrate the value of being willing to take a design down to some detail, then backtrack, start again, and see where a different design will take you. Until you do that, you may have an intuitive idea of what will and wont work, but it won't be firm. After you do this, the strengths and weaknesses of the different designs are much more concrete.
Not really knowing what to expect, I had expected that there might be more of a component of either explicit mentoring or competition involved in DesignFest. I had hoped that a really senior person could critique what we did. But DesignFest really was simply an opportunity to get together with a group of strangers and work for a day on the design of a program.
OOPSLA 2006: Day -3, Saturday, October 21
Today was spent at a "Patterns Boot Camp," meant to give us a thorough introduction to design patterns and, more importantly, the "Patterns Community".
The focus on the day was not on a specific pattern or set of patterns. Rather, it was on what makes up a pattern, why patterns are so darn useful, and what sorts of characteristics are used to distinguish between good and bad patterns.
I was surprised to find that there are people out there who are willing to act as "pattern shepherds", working with pattern authors to help patterns become clearer and more effective.
My two main new insights from the boot camp:
The focus on the day was not on a specific pattern or set of patterns. Rather, it was on what makes up a pattern, why patterns are so darn useful, and what sorts of characteristics are used to distinguish between good and bad patterns.
I was surprised to find that there are people out there who are willing to act as "pattern shepherds", working with pattern authors to help patterns become clearer and more effective.
My two main new insights from the boot camp:
- Patterns are really supposed to be documentation of proven solutions. One of the guidelines they gave us was to not use patterns to document our own ideas. A "real" pattern is one which has been shown to work effectively in the real world. Patterns are not about originality or uniqueness. Rather, they are about capturing what experts know to be true in a way that can be communicated to others.
- Patterns can be written for just about any domain. Patterns were developed originally by Christopher Alexander (an architect) and enthusiastically taken up by software developers. But there is nothing to say you could not write patterns for many other areas of human endeavor. (What might be some patterns for growing in the spiritual life, or raising a healthy and happy family?)
OOPSLA 2006: Day -4, Friday, October 20
Today I flew into Portland, OR for OOPSLA 2006. OOPSLA, as you are doubtlessly aware, is an acronym for "Object-Oriented Systems, Programming, Languages, and Applications". It is a conferences for computer-geeks of both the academic and professional variety.
As we descended for landing, I caught a glimpse of what I believe to be Mt. Hood out the window.
Subscribe to:
Posts (Atom)
Posts
