Tuesday, September 30, 2003
The Guy Responsible For Ctrl-Alt-Del
According to this article, the Ctrl-Alt-Del key sequence (aka the three finger salute) was invented by David J. Bradley as a way to reset early PCs without turning them off. There's a video clip with Bradley explaining how he "invented [Ctrl-Alt-Del] but Bill Gates made it famous". BillG's reaction is priceless. (Via SlashDot)
Lua
There are a lot of programming languages floating around but only a small percentage are in active use. Here's a programming language I hadn't heard of before that appears to have a growing user community. It's called Lua. The main aim with Lua is easy extensibility.
The language core is implemented in standard C and has been ported to lots of platforms. There's a draft of a book on Lua. I'm going to add Lua to the (growing) list of languages I want to try out.Lua is a powerful light-weight programming language designed for extending applications. Lua is also frequently used as a general-purpose, stand-alone language
GPS will pinpoint Coke prize winners
No need to worry about being followed by black helicopters anymore. Your soda can is giving away your location. But don't worry, it's just so Coca-Cola can track you down to give you the keys to your new Hummer H2. According to this article, Coca-Cola is planning a promotion next summer to use satellites to find U.S. buyers who happen to purchase special cans of Coke products. (Via BoingBoing)
Monday, September 29, 2003
Measure The Speed of Light With Chocolate and a Microwave
I haven't "tried this at home" so I'm not sure of the veracity of this approach to measuring the speed of light. It sounds like a something from the old MacGyver TV show: "A desperate physics student goes off the deep end when his science competition entry goes awry. Armed only with a Microwave oven and a chocolate bar, MacGyver must help the student determine the speed of light and win back his father's love.". 
Maven
Maven is an open-source Java project management and project comprehension tool. Maven 1.0 should be coming out soon -- the first release candidate was just announced. Looks pretty cool. I can definitely see a need for something like this. Here's an example report generated by Maven on 1.0 RC1 code. Note: this Maven is unrelated to Maven Networks.
@deprecated and backward compatibility
The @deprecated JavaDoc comment means a method or class is still usable, but you should not use it. It will gradually be phased out. Usually it means that a new method or class has been added to do the same thing. But exactly when is the old method or class removed, if ever? As it currently stands, @deprecated is an "idle threat". There's no timetable that support will ever be dropped. If a method or class was actually removed and code broke would that be okay? Would it be sufficient to say: "We told you back in JDK 1.1 that this was going to go away. You were sufficiently warned". That's impractical. Breaking running code is rarely, if ever, acceptable. So what happens? The JDK libraries get bigger over time and nothing ever goes away. That's the price we pay for backwards compatibility. At least @deprecated can trigger a warning that, for new code, you should consider other options but if the deprecation warning is in a sea of hundreds of other deprecation warnings, it's unlikely that you'll even notice it. Sigh.
Note: there's a discussion on this topic on the Sun Developer Network Forum.
Note: there's a discussion on this topic on the Sun Developer Network Forum.
Sunday, September 28, 2003
Readable Java 1.5
Not everyone is happy with the readability of Sun's proposed syntax for new features in Java 1.5. Good thing I only suggested adding named and optional parameters and didn't recommend a syntax. It's easy to ask for the features, much harder to get everyone to be happy with the syntax changes.
Is It High Time To Get Rid Of Classes?
Carlos Perez asks whether it's time to get rid of classes in reaction to an article written by James Coplien.
In Coplien's article he mentions prototype-based languages (also called delegation-based languages) as an alternative. Guess what? If you're doing web development you've probably already using one -- JavaScript. The NewtonScript language which was used to develop software for the Apple Newton MessagePad was also a prototype-based language. Even James Gosling, the father of Java, has mentioned that if he had it to do over again, he might design Java with a delegation model.
I have to admit that classes sometimes make me queasy. Using interfaces as the external exposed view with factories has been a successful design alternative but there's only so much you can do in a class-based language. I haven't considered how interfaces play in a prototype-based world but I believe that they fit into that model. The funny thing is that prototype-based systems can be used to construct class-based systems. People do this all of the time in JavaScript. The solution can't be to throw the baby out with the bath water -- we've got too much invested in what we've done in class-based languages. And we shouldn't just dump class-based languages because they don't always fit well. And besides, we don't have an adequate replacement yet -- although I know a developer who says that if we all just wrote everything in JavaScript we'd be a lot happier
In Coplien's article he mentions prototype-based languages (also called delegation-based languages) as an alternative. Guess what? If you're doing web development you've probably already using one -- JavaScript. The NewtonScript language which was used to develop software for the Apple Newton MessagePad was also a prototype-based language. Even James Gosling, the father of Java, has mentioned that if he had it to do over again, he might design Java with a delegation model.
I have to admit that classes sometimes make me queasy. Using interfaces as the external exposed view with factories has been a successful design alternative but there's only so much you can do in a class-based language. I haven't considered how interfaces play in a prototype-based world but I believe that they fit into that model. The funny thing is that prototype-based systems can be used to construct class-based systems. People do this all of the time in JavaScript. The solution can't be to throw the baby out with the bath water -- we've got too much invested in what we've done in class-based languages. And we shouldn't just dump class-based languages because they don't always fit well. And besides, we don't have an adequate replacement yet -- although I know a developer who says that if we all just wrote everything in JavaScript we'd be a lot happier
Objective-C
Objective-C has been getting attention in the past few years because the Cocoa application environment on Mac OS X is written in it. Cocoa is the descendant of the NeXTStep AppKit environment.
The Objective-C language was developed by PPI in the 1980s. It added Smalltalk-like object-oriented extensions to ANSI C -- a more conservative approach than C++. Objective-C has full metaclasses like Smalltalk and all method invocations are dynamic. The PPI compiler generated ANSI C and included a small runtime to do method dispatching. NeXT licensed the language from PPI and extended GCC to support Objective-C natively. In 1993, NeXT got out of the hardware business and NeXTStep morphed into OpenStep which was supported on a variety of different platforms including Solaris. In 1997, Apple acquired NeXT and the NeXT AppKit was transformed into Cocoa.
But what's cool about Objective-C? The main distinction is that, unlike C++, types are preserved at runtime and method calls use dynamic binding. The Cocoa runtime needs this type of dynamism to work. Also, Objective-C, like Java, has a single-inheritance hierarchy but supports a mechanism called protocols which allow classes to define the interfaces that they support. It's not a big surprise that Cocoa supports both Objective-C and Java as development languages. In fact, the folks at Apple pushed for Java to get type introspection features like those supported in Objective-C in order for Java to be a useful language for developing Cocoa applications.
The Objective-C language is "good enough" for building dynamic applications. But if that was all that was there, it would have remained an intellectual curiosity. What really makes the language useful is the Cocoa environment itself. The NeXTStep AppKit heritage comes through (note that most of the class names use the prefix "NS" for NextStep). The NeXTStep AppKit was the nicest GUI application framework I've used. It did a great job of hiding complexity and was a natural "fit" for the language. Kudos to Apple for recognizing the value of this technology and keeping the AppKit and Objective-C alive.
The Objective-C language was developed by PPI in the 1980s. It added Smalltalk-like object-oriented extensions to ANSI C -- a more conservative approach than C++. Objective-C has full metaclasses like Smalltalk and all method invocations are dynamic. The PPI compiler generated ANSI C and included a small runtime to do method dispatching. NeXT licensed the language from PPI and extended GCC to support Objective-C natively. In 1993, NeXT got out of the hardware business and NeXTStep morphed into OpenStep which was supported on a variety of different platforms including Solaris. In 1997, Apple acquired NeXT and the NeXT AppKit was transformed into Cocoa.
But what's cool about Objective-C? The main distinction is that, unlike C++, types are preserved at runtime and method calls use dynamic binding. The Cocoa runtime needs this type of dynamism to work. Also, Objective-C, like Java, has a single-inheritance hierarchy but supports a mechanism called protocols which allow classes to define the interfaces that they support. It's not a big surprise that Cocoa supports both Objective-C and Java as development languages. In fact, the folks at Apple pushed for Java to get type introspection features like those supported in Objective-C in order for Java to be a useful language for developing Cocoa applications.
The Objective-C language is "good enough" for building dynamic applications. But if that was all that was there, it would have remained an intellectual curiosity. What really makes the language useful is the Cocoa environment itself. The NeXTStep AppKit heritage comes through (note that most of the class names use the prefix "NS" for NextStep). The NeXTStep AppKit was the nicest GUI application framework I've used. It did a great job of hiding complexity and was a natural "fit" for the language. Kudos to Apple for recognizing the value of this technology and keeping the AppKit and Objective-C alive.
Should Java support named and optional arguments?
Java 1.5 will extend the language with a number of nice features such as generics, autoboxing, enums, etc. Unfortunately, named and optional arguments aren't on the list. That's too bad. I believe that they would make the language easier to use and would not substantially increase compiler or runtime complexity.
Named (or keyword) arguments are supported in quite a few programming languages. They address shortcomings of so-called positional arguments. It's easiest to show the distinction with an example. First positional arguments in Java:
Named arguments are especially useful when combined with optional arguments (e.g. arguments with default values). C++ has support for optional arguments but not named arguments making them less useful. When a language only support optional arguments, and you want to specify the value of the second optional argument of a method that takes two optional arguments, you have to specify values for both optional arguments. When you combine named and optional arguments, you would only need to specify the second one.
Named and optional arguments are syntactic sugar. That's one reason I think they would be easy to add to the language. Maybe I should petition Sun to get them into Java 1.6 In the meantime, we can simulate these features. Optional arguments can be simulated by overloading a method with two different signatures. For example:
Named arguments can be simulated somewhat but they're a little trickier. The simplest technique is to create a value object to hold the arguments rather than pass them explicitly. Not as slick but the net effect can be similar. Another approach would be to use a HashMap as a general argument container. The downsides to this approach are that you lose type safety and you'd need to document the keys and types of the expected values. Pretty messy.
So what do you think? Should Java support named and optional method arguments?
Named (or keyword) arguments are supported in quite a few programming languages. They address shortcomings of so-called positional arguments. It's easiest to show the distinction with an example. First positional arguments in Java:
widget.handleIt( 1, 2, true, false );Next, named arguments in a hypothetical extension to Java:
widget.handleIt( x: 1, y: 2, show: true, enable: false );Because the arguments are no longer positional, this invocation would be legal as well:
widget.handleIt( show: true, enable: false, x: 1, y: 2, );Lots of programming languages support named arguments (e.g. Python, Ruby, Lisp). Even C# supports named arguments. But not Java.
Named arguments are especially useful when combined with optional arguments (e.g. arguments with default values). C++ has support for optional arguments but not named arguments making them less useful. When a language only support optional arguments, and you want to specify the value of the second optional argument of a method that takes two optional arguments, you have to specify values for both optional arguments. When you combine named and optional arguments, you would only need to specify the second one.
Named and optional arguments are syntactic sugar. That's one reason I think they would be easy to add to the language. Maybe I should petition Sun to get them into Java 1.6
In the meantime, we can simulate these features. Optional arguments can be simulated by overloading a method with two different signatures. For example:public void aMethod(int value) {This works okay but when you have a lot of arguments the number of methods can grow to a ridiculous number. And each calls the other in turn, filling the callstack with noise.
aMethod(value, true);
}
public void aMethod(int value, boolean flag) {
// do something useful
}
Named arguments can be simulated somewhat but they're a little trickier. The simplest technique is to create a value object to hold the arguments rather than pass them explicitly. Not as slick but the net effect can be similar. Another approach would be to use a HashMap as a general argument container. The downsides to this approach are that you lose type safety and you'd need to document the keys and types of the expected values. Pretty messy.
So what do you think? Should Java support named and optional method arguments?
Saturday, September 27, 2003
Blog spammers
Comment systems on most blogs have wide open access. Anyone can add a comment; no authentication needed. It looks like a spammer has decided to exploit this by spamming blogs with one of those *cough* *cough* body part enlargement offers. Such weasels.
Friday, September 26, 2003
Smalltalk report archive
This is cool. An archive of the Smalltalk Report is available online here.
When I attended the first OOPSLA conference in 1986, most of the papers were on Smalltalk. Lots of companies (including IBM) got on the Smalltalk bandwagon in a big way. Commercial Smalltalk environments were available from ParcPlace Systems, Digitalk, IBM, etc. on everything from DOS to Macintoshes to Unix workstations. Other OOP languages, especially C++ came into their own a few years later.
Smalltalk started a slow decline in usage through the mid 90s, especially when Java came along. It could be argued that Smalltalk had a longer and more viable commercial life than other dynamic languages such as Lisp but it never "broke through" as a general-purpose language. A revival of interest in Smalltalk seems to be happening, especially as a result of Squeak programming environment. If you're looking to read about Smalltalk, the best place to start is with the classic book Smalltalk-80: The Language. This book on Squeak is pretty good as well. (Via . Lambda the Ultimate)
When I attended the first OOPSLA conference in 1986, most of the papers were on Smalltalk. Lots of companies (including IBM) got on the Smalltalk bandwagon in a big way. Commercial Smalltalk environments were available from ParcPlace Systems, Digitalk, IBM, etc. on everything from DOS to Macintoshes to Unix workstations. Other OOP languages, especially C++ came into their own a few years later.
Smalltalk started a slow decline in usage through the mid 90s, especially when Java came along. It could be argued that Smalltalk had a longer and more viable commercial life than other dynamic languages such as Lisp but it never "broke through" as a general-purpose language. A revival of interest in Smalltalk seems to be happening, especially as a result of Squeak programming environment. If you're looking to read about Smalltalk, the best place to start is with the classic book Smalltalk-80: The Language. This book on Squeak is pretty good as well. (Via . Lambda the Ultimate)
Escape from... High Tech
Jeff Anderholm was the product manager for Lotus Improv. When I joined the project we had 25 people - the right size to show the Birthday Paradox in action (the odds of two people in a group having the same birthday exceeds 50% in a group of 23). Not only do Jeff and I share the same birthday, we were born in the same year as well. Jeff has made a career change that a lot of us consider from time to time. He bailed out of high tech. He and his wife bought an Inn in Bar Harbor, Maine and are becoming innkeepers.
Vanity domain names
I wanted to own a domain even before I knew what I would do with it. Ownership can be like that. I registered bobcongdon.com a few years ago after discovering that all of the common top level domains for my surname had already been taken. I decided that I would own my full name in the .com domain. Fortunately my name is not particularly common so no one else had already grabbed it. I don't like the fact that domain registration is basically a "land grab" and there's little to prevent someone else from registering thousands of domain names in speculation that someone might want them in the future.
I've registered a few other domains for other purposes. Domains definitely can come in handy for web site and email redirection. The latter has been especially useful for giving out stable email addresses and setting up group email aliases.
I've registered a few other domains for other purposes. Domains definitely can come in handy for web site and email redirection. The latter has been especially useful for giving out stable email addresses and setting up group email aliases.
DB2 SQL Cookbook
Relational databases are conceptually simple but complex in detail. SQL is an industry standard but you need to be aware of vendor-specific details. If you're working with DB2 on Windows or Unix platforms you should download a copy of Graeme Birchall's DB2 SQL cookbook. The latest version covers DB2 UDB 8.1. Note: a lot more information on DB2 including Redbooks, documentation, articles, etc. can be found here
Thursday, September 25, 2003
Early Adopters or Trend Surfers?
Good thought piece on Hacknot about how we (software developers) willingly embrace the latest software technologies but balk at using software development "best practices".
Lost In Translation
I saw Sophia Coppola's Lost In Translation this evening. It's a terrific film. Bill Murray plays an American movie star (Bob) in Tokyo to shoot a whiskey commercial. Scarlett Johansson plays Charlotte, the wife of a workaholic photographer also in Tokyo. Bob and Charlotte cross paths in the bar of the hotel they both are staying in. They are both sad, lonely characters, lost in a strange place. There are some funny scenes but this is not a comedy. The relationship between the two characters evolves slowly, and not in the way you might expect.
By the way, if you go see the film, the NY Times has a translation of what the Japanese director is saying to Bill Murray's character.
By the way, if you go see the film, the NY Times has a translation of what the Japanese director is saying to Bill Murray's character.
The Great Boston Molasses Flood of 1919
Anyone who grew up or has lived in the Boston area has heard something about the "molasses flood" in Boston's North End. It sounds like an urban legend but it really happened. According to this article , a tank filled with over 2 million gallons of molasses ruptured, killing 21 people. A book about the disaster, Dark Tide : The Great Boston Molasses Flood of 1919 has just been published.
Cheeseburger Fries
I had my cholesterol levels checked recently. Everything is good, thanks for asking I don't eat meat (a personal choice). Even if I did, here's something that I'd stay away from. To quote Homer Simpson:"You mean grease is money?!? Woo hoo! my arteries are filled with yellow gold!"
I don't eat meat (a personal choice). Even if I did, here's something that I'd stay away from. To quote Homer Simpson:"You mean grease is money?!? Woo hoo! my arteries are filled with yellow gold!"
Google Search by Location
Google has a new "search by location" feature. You should try it out. Note: according to the FAQ it's still a "work in progress" and so it may be down from time to time.
Wednesday, September 24, 2003
24 x 80
Back when dinosaurs roamed the earth, the 24 lines by 80 column "dumb" terminal was how most people interacted computers. It was crappy but compared to punch cards and teletypes, it was "interactive" computing. But why did terminals have 80 columns? Because a standard IBM punch card had 80 columns. Then why 24 lines? I'm not as sure of this but I believe it was related to the aspect ratio of the displays used in terminals. Video displays capable of even this resolution were quite expensive. A DEC VT220 cost something like $2K brand new. Of course, around the same time a 1200 baud analog modem cost about $700 (!).
vt100.net is a web site dedicated dumb terminals produced by DEC including, of course, the classic VT100. There's also information on a variety of other terminal vendors there as well. (Inspired by Ned's discussion on Proggy fonts)
vt100.net is a web site dedicated dumb terminals produced by DEC including, of course, the classic VT100. There's also information on a variety of other terminal vendors there as well. (Inspired by Ned's discussion on Proggy fonts)
You can call me Ray, you can call me Jay...
Comedian Bill Saluga had a bit that he did on TV variety shows. If you watched television in the late 70s you'll remember it. A zoot-suited character named Raymond J. Johnson Jr. would appear. If you called him "Johnson," he launched into a tirade:
I was reminded of this bit when I met someone the other day. He introduced himself as his first and middle initial (e.g. RJ). As someone who prefers Bob over Robert I can appreciate the need to clearly state a preference up front. When someone insists on calling me Robert after I've told them that my name is Bob I can get a little irritated. Our preferences can change over time. My sister was known as Kathy growing up and requested that we start calling her Kate when she was in her 20s. Sometimes we have different names for different contexts. I known several people who are known by a diminuitive to parents, siblings and old friends (e.g. Joey) who would cringe if a co-worker used the same name.
It was one of those routines that was funny once or twice but became tiresome when it was trotted out for the 100th time to get a cheap laugh. Also, I'd imagine, it was a tough way for Saluga to make a living. Squeeze in as many appearances as possible before your agent stops getting calls.Ahh, ya doesn't has to call me Johnson! You can call me Ray, or you can call me Jay, or you can call me Johnny or you can call me Sonny, or you can call me RayJay, or you can call me RJ... but ya doesn't hafta call me Johnson
I was reminded of this bit when I met someone the other day. He introduced himself as his first and middle initial (e.g. RJ). As someone who prefers Bob over Robert I can appreciate the need to clearly state a preference up front. When someone insists on calling me Robert after I've told them that my name is Bob I can get a little irritated. Our preferences can change over time. My sister was known as Kathy growing up and requested that we start calling her Kate when she was in her 20s. Sometimes we have different names for different contexts. I known several people who are known by a diminuitive to parents, siblings and old friends (e.g. Joey) who would cringe if a co-worker used the same name.
Tuesday, September 23, 2003
Oakum
My first project at Lotus was a multi-dimensional spreadsheet called Lotus Improv. The first release didn't include a programming environment (e.g. anything like Office VBA) but one was in the works. The language for this environment was called "Oakum". The main developer was enamored with building wooden ships and "oakum" is a material used to caulk the seams in ships (kind of like glue).
Oakum's syntax was similar to HyperTalk / HyperScript which looks less like a traditional programming language; more chatty like Logo. It was pretty slick. Unfortunately for Oakum, Lotus decided that it would be better to standardize on a single embedded programming language / IDE for all desktop products. That language was LotusScript which first shipped as part of Improv 2.0 for Windows. LotusScript eventually shipped with all Lotus products including Notes/Domino. It was a better business decision than going with Oakum since LotusScript is relatively easy to learn if you already knew Visual Basic. But I thought Oakum was a such cool name for a scripting language.
By the way, the original name for the Java programming was Oak (so called because there was an oak tree outside James Gosling's office window). Oak came a few years after Oakum's conception, development and demise. They're unrelated except for having similar names.
Oakum's syntax was similar to HyperTalk / HyperScript which looks less like a traditional programming language; more chatty like Logo. It was pretty slick. Unfortunately for Oakum, Lotus decided that it would be better to standardize on a single embedded programming language / IDE for all desktop products. That language was LotusScript which first shipped as part of Improv 2.0 for Windows. LotusScript eventually shipped with all Lotus products including Notes/Domino. It was a better business decision than going with Oakum since LotusScript is relatively easy to learn if you already knew Visual Basic. But I thought Oakum was a such cool name for a scripting language.
By the way, the original name for the Java programming was Oak (so called because there was an oak tree outside James Gosling's office window). Oak came a few years after Oakum's conception, development and demise. They're unrelated except for having similar names.
Mainsail and garbage collection
I was thinking about a garbage collector issue earlier today and was reminded of the Mainsail programming language. When I worked at Cognition, we wrote a Mechanical CAE product in Mainsail. It looks like an object-oriented dialect of Pascal but is a bit older -- it's in the ALGOL / Simula family. Mainsail has a number of cool features, dynamic loading, modules, garbage collection, dynamic strings, etc. and it's extremely portable. The unusual thing about Mainsail garbage collection is that it's a hybrid. You can let the GC kick in and reclaim space or you can call delete on an object that you no longer need. It was beneficial to do explicit deletion since allowed us to reduce the frequency of GC. But, if you used delete you had the same downside of a non-GC language. If you called delete you needed to make sure that you had no other references to the object, otherwise... Crash!. I can't think of another language that has this type of hybrid approach to memory reclamation.
Monday, September 22, 2003
Maven Networks
Maven Networks released its Maven Media System today. A few friends and ex-coworkers from Lotus and Iris are working at Maven. I wish them well. As with any startup venture it's a crap shoot but Maven's software looks pretty cool. Jeremy Allaire is on their Board of Advisors and has written his impressions on his weblog
Sunday, September 21, 2003
Superpowers and The Segway
I listened to an old episode of This American Life the other day. It was the one about Superpowers. In one segment they asked people whether they'd rather have the power of flight or invisibility. The answers were interesting. Some people gave it a lot of thought and tried to interpret what it meant to pick one or the other. Not a single person said anything about wanting to "fight crime" with their superpower. Personally, I wouldn't pick flight. It sounds cool but I don't like to call attention to myself. I'd definitely pick invisibility. Yeah, it's kind of a sneaky power but I'd use it only "for good". I promise.
On a related note, while driving through Winchester Center earlier today, I saw someone "driving" down the street on a Segway. It was a beautiful sunny day and he looked happy but everyone was gawking at him. Despite the fact that it only goes 5-10 mph, there's a definite coolness to the Segway. But I don't think I could take the gawkers. So, yes I'd definitely pick invisibility over the power of flight.
On a related note, while driving through Winchester Center earlier today, I saw someone "driving" down the street on a Segway. It was a beautiful sunny day and he looked happy but everyone was gawking at him. Despite the fact that it only goes 5-10 mph, there's a definite coolness to the Segway. But I don't think I could take the gawkers. So, yes I'd definitely pick invisibility over the power of flight.
Windows to Power ATMs in 2005
Several years ago I saw a technician working on an ATM. With the front cover removed I could see the screen inside displaying OS/2 Presentation Manager. It turns out that most ATMs today still run OS/2. That's going to change soon. According to this article on Wired News, by 2005 65 percent of bank ATMs will use a stripped-down version of Windows. Wow. Let's hope they strip out all of the "bad" parts
Refactoring Catalog
I was reading Ned's link to Martin Fowler's entry on Technical Debt. Great term. We incure "technical debt" all of the time -- sometimes the debt is short term and we recover quickly, other times we're saddled with crippling interest payments (bad design) and curse the short-sighted decisions made by our earlier self (or a predecessor).
I started reading the rest of Martin Fowler's blog. Good content and links including a updated version of the Refactoring Catalog from his book.
I started reading the rest of Martin Fowler's blog. Good content and links including a updated version of the Refactoring Catalog from his book.
Refactoring for everyone
Good article on using Eclipse's refactoring tools on IBM's developerWorks web site.
Robert Cringley has been ranting about refactoring in a couple recent articles:Eclipse provides a powerful set of automated refactorings that, among other things, let you rename Java elements, move classes and packages, create interfaces from concrete classes, turn nested classes into top-level classes, and extract a new method from sections of code in an old method. Becoming familiar with Eclipse's refactoring tools is a good way to improve your productivity. This survey of Eclipse's refactoring features, with examples, demonstrates how and why to use each.
Certainly the term "refactoring" has been overused. It should not be applied to arbitrary "code cleanup". Martin Fowler's response to Cringley is good and makes the distinction clear.Refactoring means monkeying with working code. If the program isn’t working, you don’t refactor it. Refactoring is supposed to be IMPROVING code, not fixing it. By definition, you only refactor code that is already working, which where I come from is scary. Working code is a valuable asset since it is hard to get right (at least for me) and takes time. Touching working code is always a risk and so there should be a darned good reason for doing it. Adding features, worthwhile refactoring, or bug fixing are all possible good reasons. Tinkering with code or cleaning it up is not.
Pete Lyons
Pete Lyons, a friend and co-worker, has been working on his blog for a while but hasn't told many people about it -- mostly just me . I've made a couple of links to it here and thought that I'd make an "official" announcement. Some folks may remember Pete from his work on the Domino Designer. Pete has broad technical interests and a great sense of humor. Plus he has a much cooler blog name than mine: DevelopingStorm. Check it out.
. I've made a couple of links to it here and thought that I'd make an "official" announcement. Some folks may remember Pete from his work on the Domino Designer. Pete has broad technical interests and a great sense of humor. Plus he has a much cooler blog name than mine: DevelopingStorm. Check it out.
Change your programming perspective
Sometimes it's healthy to change your perspective a bit. To give your brain a different spin on how the world works. A number of years ago I traveled to England on a business trip. I stayed for a month and rented a car to get around. My first experience driving on the left side of the road (from Heathrow Airport to Cambridge) was a little unnerving but I got the hang of it pretty quickly. I had to deal with a lot of smaller differences as well: traffic flow, navigating through roundabouts, understanding the traffic signs, etc. Occasionally there was a moment of panic when my brain tried to revert to American driving. In one case I was trying to quickly pull over to the side to let another car pass in a narrow street; in another I was pulling up to a toll booth to pay. Fortunately, I recovered before making a mistake. When I returned to Boston and got into my car and started to drive and thought "which side is it now?" but I was able to rely on my "muscle memory" of American driving without too much difficulty.
Programming languages can be good at changing your perspective too. If you've been coding in one language (e.g. C/C++ or Java) for a while, it's worth the trouble to learn another language. And not just to make yourself more "marketable". A different programming language can change the way you think about solving problems, especially when you embrace the new language's style and idioms.
Which language to pick? In some ways it doesn't matter as long as it's sufficiently different from what you use now. It helps to know someone else who's already fluent in the language (although with the web you can find language communities). A language that you might find useful for other things (e.g. a scripting language such as Perl or Python) might be a good choice. I'd also recommend trying one of the more "classic" languages such as Lisp or Smalltalk. Excellent open source / freeware environments exist for nearly any choice you make. For example there's an wonderful open source Smalltalk environment called Squeak that runs on just about any platform you can imagine.
So go ahead, change your programming perspective a bit.
Programming languages can be good at changing your perspective too. If you've been coding in one language (e.g. C/C++ or Java) for a while, it's worth the trouble to learn another language. And not just to make yourself more "marketable". A different programming language can change the way you think about solving problems, especially when you embrace the new language's style and idioms.
Which language to pick? In some ways it doesn't matter as long as it's sufficiently different from what you use now. It helps to know someone else who's already fluent in the language (although with the web you can find language communities). A language that you might find useful for other things (e.g. a scripting language such as Perl or Python) might be a good choice. I'd also recommend trying one of the more "classic" languages such as Lisp or Smalltalk. Excellent open source / freeware environments exist for nearly any choice you make. For example there's an wonderful open source Smalltalk environment called Squeak that runs on just about any platform you can imagine.
So go ahead, change your programming perspective a bit.
Saturday, September 20, 2003
Olympic Security English
Beijing has created a 252-page Olympic Security English textbook for their police to deal with foreigners during the 2008 Olympics. The book includes such useful English phrases as "Shut up, so we can finish our search".
Friday, September 19, 2003
Talk Like A Pirate Day
Today is Talk Like A Pirate Day Arrh!
RSS Feed
I added an RSS feed for this blog. This is experimental for now. Let me know if it works for you. 
The Google Vanity Search
Google now lists me first among all of the Bob Congdons in the universe. Take that Bob Congdon of Bob's Old Buildings and Connecticut State Representative Bob Congdon.
My fan club
I got some feedback in my blog comments from someone named "jen":
Clearly, not everyone is going to be interested in what I have to say. Jen may have followed the link from Bloglet which isn't just a list of geeky blogs. Oh well.this site really sucks and is boring..i found no helpful information
Thursday, September 18, 2003
Matchstick Men
Just saw Matchstick Men. I think I'm going to avoid movies with con artist / "one last heist" plotlines for now. Especially since they all seem to conclude with incredibly implausible "twist" endings. There have been a lot of these recently (e.g. The Score, Confidence, The Italian Job, etc). Matchstick Men has a good cast: Nicholas Cage, Sam Rockwell and especially Alison Lohman. And the first two-thirds of the film are enjoyable but I hated being led down the primrose path in the third act. My advice: go rent Adaptation and see Nicholas Cage in a much better movie.
Note: in this movie Matchstick Men is a term for con artists. I hadn't heard that usage before. The first thing that came to mind was the song Pictures of Matchstick Men which doesn't seem to be related. In fact, it's hard to tell what that song is about. Sounds like a bad acid trip...
Note: in this movie Matchstick Men is a term for con artists. I hadn't heard that usage before. The first thing that came to mind was the song Pictures of Matchstick Men which doesn't seem to be related. In fact, it's hard to tell what that song is about. Sounds like a bad acid trip...
Wednesday, September 17, 2003
Bloglet
I'm probably going overboard with blogging cruft on this page. I just set up this blog to work with Bloglet, an email subscription service for blogs. It uses XML-RPC under the covers and only works with certain blogging tools (including Blogger). If you'd rather get notified via email when new content shows up here, scroll to the bottom of the page, enter your email address and give it a try.
Who died and made you Elvis?
Ben Langhinrichs has a weblog entry with this wonderful title. The entry concerns how browsers and Notes/Domino handle HTML table rendering. I worked on the Domino web server from the beginning until R6. We wrestled with these issues all of the time. The choice of how to render something often boiled down to whether to generate HTML that looked similar to the Notes client or more in the spirit of what things commonly look like in a browser. Usually we chose to make things look more like Notes. That made developers who wanted to deploy Notes applications to the web happy; it made web-focused developers less happy.
Over time, it became more and more difficult to the change the way Notes documents were rendered as HTML. Designers and developers had become dependent on each detail of how our CD record to HTML translation behaved. Whether we liked it or not, we were painting ourselves into a corner. Sometimes it was possible to "find fresh unpainted floor" by inventing new concepts but existing behavior had to be preserved.
The Elvis comment is appropriate to the developers of the Domino engine. We were making King like decisions all along. How dare we? Well, we had no idea at the time. We would likely make some different choices if we were writing one from scratch now. But would the choices we make now be the right ones in five years? Who knows. It's not easy being the King sometimes.
Over time, it became more and more difficult to the change the way Notes documents were rendered as HTML. Designers and developers had become dependent on each detail of how our CD record to HTML translation behaved. Whether we liked it or not, we were painting ourselves into a corner. Sometimes it was possible to "find fresh unpainted floor" by inventing new concepts but existing behavior had to be preserved.
The Elvis comment is appropriate to the developers of the Domino engine. We were making King like decisions all along. How dare we? Well, we had no idea at the time. We would likely make some different choices if we were writing one from scratch now. But would the choices we make now be the right ones in five years? Who knows. It's not easy being the King sometimes.
Brozilla is staring at you
While cleaning out some old email, I found a reference to Brozilla, a totem we used at Blue Ripple. It was a plastic Godzilla toy. If you checked in code that screwed up the build, Brozilla was put on your desk as a "scarlet letter" so you wouldn't do it again. You got stuck with Brozilla until the next person screwed up. This was inspired by something we had done at Applicon years ago. An coconut carved to look like a gorilla head was hung outside your cubicle if you broke the build.
In both cases, it was all in good fun but I have to admit that the last time I got Brozilla on my desk I was pissed. I had just worked on some new feature, carefully checked my changes multiple times and the build broke because of an overlooked classpath problem. I worked hard on the code and felt that getting Brozilla as a result was bogus. I vented by writing an email missive about how Brozilla seemed to be against the spirit of working as a team (or something like that) and that I was going to keep Brozilla and not pass it along again. Yeah, it was just me venting. I rarely do that via email. I calmed down and Brozilla got passed around for few more months until Blue Ripple went under. Brozilla lives on as its own web site. You can see our obscure piece of failed Dot Com history here. (Btw, I think Brozilla is standing on a copy of our Beta Release plans!).
I currently work on a much larger software project. Builds break on a regular basis. We don't have a Brozilla equivalent - it would be pretty difficult to pass around anyway since we have developers in several countries. Sometimes breakage is the result of sloppy or careless coding -- fortunately that's rare. Sometimes breakage is a result of miscommunication between developers. Refactoring is sometimes a cause as well. Refactoring code on a large project, even when you have access to all the code and have effective refactoring tools is hard -- especially when you have multiple development streams. When lots of code is changing at the same time, team size gets in the way. It can feel like the old Three Stooges routine where Moe, Larry and Curly all try to get through a door at the same time. The harder they struggle, the less likely any of them will get through the door. Breakage is inevitable when too many people try to change the same code at the same time.
Refactoring on a large project can be compared to the Big Dig central artery project here in Boston. It was hard enough to do the project in the first place but the really hard (and expensive) part is that Boston can't shut down while they work on it. The project needs to progress incrementally; allowing the city to still operate. This adds (and adds and adds...) to the overall cost of the project. The end result is a compromise from might have done if they had had free rein. Software refactoring can be like that too. Big changes need to be scheduled carefully and you have to avoid breaking existing code while you're changing the underlying support.
It's easy to say "Well, you have interfaces, right? Just change the underlying implementation and no one should notice." That's true to extent when interfaces have matured but interfaces evolve. And sometimes they're just plain wrong or requirements have changed to such an extent that you need to rethink your approach.
Comment time again: how does your development team deal with build breakage? How do you avoid it? What do you do with repeat offenders?
(Note: Brozilla belongs to Andrew Wharton. Here's a photo of Andrew and Brozilla in earlier times at Iris. It looks like Smart Money's Map of the Market on his screen. Very different stock market way back in 1999...)
In both cases, it was all in good fun but I have to admit that the last time I got Brozilla on my desk I was pissed. I had just worked on some new feature, carefully checked my changes multiple times and the build broke because of an overlooked classpath problem. I worked hard on the code and felt that getting Brozilla as a result was bogus. I vented by writing an email missive about how Brozilla seemed to be against the spirit of working as a team (or something like that) and that I was going to keep Brozilla and not pass it along again. Yeah, it was just me venting. I rarely do that via email. I calmed down and Brozilla got passed around for few more months until Blue Ripple went under. Brozilla lives on as its own web site. You can see our obscure piece of failed Dot Com history here. (Btw, I think Brozilla is standing on a copy of our Beta Release plans!).
I currently work on a much larger software project. Builds break on a regular basis. We don't have a Brozilla equivalent - it would be pretty difficult to pass around anyway since we have developers in several countries. Sometimes breakage is the result of sloppy or careless coding -- fortunately that's rare. Sometimes breakage is a result of miscommunication between developers. Refactoring is sometimes a cause as well. Refactoring code on a large project, even when you have access to all the code and have effective refactoring tools is hard -- especially when you have multiple development streams. When lots of code is changing at the same time, team size gets in the way. It can feel like the old Three Stooges routine where Moe, Larry and Curly all try to get through a door at the same time. The harder they struggle, the less likely any of them will get through the door. Breakage is inevitable when too many people try to change the same code at the same time.
Refactoring on a large project can be compared to the Big Dig central artery project here in Boston. It was hard enough to do the project in the first place but the really hard (and expensive) part is that Boston can't shut down while they work on it. The project needs to progress incrementally; allowing the city to still operate. This adds (and adds and adds...) to the overall cost of the project. The end result is a compromise from might have done if they had had free rein. Software refactoring can be like that too. Big changes need to be scheduled carefully and you have to avoid breaking existing code while you're changing the underlying support.
It's easy to say "Well, you have interfaces, right? Just change the underlying implementation and no one should notice." That's true to extent when interfaces have matured but interfaces evolve. And sometimes they're just plain wrong or requirements have changed to such an extent that you need to rethink your approach.
Comment time again: how does your development team deal with build breakage? How do you avoid it? What do you do with repeat offenders?
(Note: Brozilla belongs to Andrew Wharton. Here's a photo of Andrew and Brozilla in earlier times at Iris. It looks like Smart Money's Map of the Market on his screen. Very different stock market way back in 1999...)
Tuesday, September 16, 2003
Naming is hard
Naming is a distinctly human activity. We name things all of the time but, really, it's hard work. Names are weighty things; they can communicate intended and unintended meaning and can outlive the "namer" by years, decades or centuries. In software development we sometimes seem to forget this and treat names that we produce as something only we look at. But in truth, names are important.
Coming up with good package, class, interface and method names can be tough. You should define naming convention to insure that names predictable (e.g. class names start with a capital letter, use "came case" for names, etc) but you still need to come up with unique names within those conventions. Part of the difficulty with software objects is that sometimes there aren't "real world" equivalents to use for inspiration. So we tend to fall back on the same old names when we can't think of anything else. We resort to generic names such as "Element" or "Document". Worse yet, on large software projects there may be thousands of names. Having five different classes called "Document" makes coding onerous, especially if you need to write code that uses more than one of them at a time.
So what to do? Here are a few suggestions:
(Note: one day I'll update the design of this blog and have a place for longer writings. For now, stuff like this will go here.).
Coming up with good package, class, interface and method names can be tough. You should define naming convention to insure that names predictable (e.g. class names start with a capital letter, use "came case" for names, etc) but you still need to come up with unique names within those conventions. Part of the difficulty with software objects is that sometimes there aren't "real world" equivalents to use for inspiration. So we tend to fall back on the same old names when we can't think of anything else. We resort to generic names such as "Element" or "Document". Worse yet, on large software projects there may be thousands of names. Having five different classes called "Document" makes coding onerous, especially if you need to write code that uses more than one of them at a time.
So what to do? Here are a few suggestions:
- Take naming seriously as an important part of your design.
- If there's someone on your team who is especially creative with names, explain what your package, class, interface, etc. is supposed to do and ask them what names they would use.
- If the class or interface is similar to something that already exists, create a derivative, related name.
- Conversely, don't use a derivative name if the class or interface is not related to something else (e.g. in Java don't use a class name like XyzCoolioStream if the class is not derived from or similar in concept to a java.io Stream).
- It's okay to shorten words or use acronyms but try to be consistent when you do this.
- After coming up with a set of names try them out on a peer, especially if the peer is someone who might be writing code that will rely on these names.
- It's okay to change your mind if a name no longers fits. For example, if the purpose of the class morphed into something else. It's often better to change the name, if possible, than to leave a misleading name as is
(Note: one day I'll update the design of this blog and have a place for longer writings. For now, stuff like this will go here.).
Monday, September 15, 2003
Semaphores and Great Literature
Pete's link to the Maritime Signal and Semaphore Flags web site reminded me of one of the more bizarre (and I mean that in a good way) sketches on the Monty Python show -- The Semaphore Version of Wuthering Heights. (Via Pete)
Bend It Like Beckham
We watched Bend It Like Beckham over the weekend. It's an enjoyable coming-of-age film with an English / Indian culture clash thrown in for good measure. Nothing weighty here but quite enjoyable. The dream of the main character was to move to the United States and to play in WUSA (Women's United Soccer Association) -- there's no professional women's soccer league in the UK. As of today, the same is true in the United States. WUSA just shut down operations.
Spamalot
A stage version of the movie "Monty Python and the Holy Grail" will open in New York in the spring of 2005. Its tentative title is Spamalot. (From the lyrics in the film: "We dine well here in Camelot. We eat ham and jam and Spam a lot."). This kind of Spam not this kind
Movie Soundtracks
The Rolling Stones "Paint It Black" was playing on the radio this morning. I'd forgotten how terrific that song was. It was used to great effect playing over the end credits in "Full Metal Jacket" (although it doesn't appear on the movie soundtrack). Which brings me to my topic. I love movie soundtracks. Movies and music are inseparable in my mind. Often the music can stand on its own -- as original music (e.g. the soundtrack for Fargo) or as a collection of older and sometimes obscure music (e.g. Pulp Fiction). Sometimes, for me, the music is better than the movie and more enjoyable when it's separate from the movie (e.g. Wim Wender's Until The End of the World)
Sunday, September 14, 2003
Web Fire Escape
"The Web Fire Escape is a simple device which has been designed to allow readers of weblogs to instantly replace a Web Fire Escape equipped blog with an alternate work-safe site or a fake word processor or spreadsheet application. When you see a weblog with the Web Fire Escape equipped button 
you can be sure that career salvation is only a click away should a work colleague or manager approach your desk whilst you are catching up with your daily blogs".
I can't imagine why anyone would ever need such a thing(Via evhead)
you can be sure that career salvation is only a click away should a work colleague or manager approach your desk whilst you are catching up with your daily blogs".
I can't imagine why anyone would ever need such a thing
(Via evhead)
Friday, September 12, 2003
Java Case Studies
Some interesting Java case studies from JavaOne in this entry on Artima. I found the case study on eBay to be especially impressive. 69 million users; 380 million page views per day; 1 billion per day expected within 2 years. And the system that the Java-based solution replaced was a 3.3 million line C++ ISAPI DLL (!).
Thursday, September 11, 2003
Drawing UML Diagrams with Gesture Recognition
Brian and I were talking the other day about being able to draw freehand diagrams that could be automatically recognized and cleaned up. It turns out that there are some tools that can do that now. The Ideogramic Ideas and Ideogramic UML tools can be used to produce general diagrams and UML diagrams. They use a simple form of gesture recognition to turn sketches into diagrams. (Via Hacknot)
Gesture Recognizer
Early in my career I worked at Applicon, a CAD/CAM software vendor. One of the cool features of Applicon's CAD system was a tablet interface that allowed you to associate pen stroke gestures with commands. For example, you might draw a "Z" and associate it with a "zoom" command using the bounds of the gesture as the new zoom rectangle. It was amazingly productive once you learned to use it. The gesture recognizer used by Applicon was a derivative of the Ledeen-Teitelman recognizer described in the second edition of Newman and Sproull's Principles of Interactive Computer Graphics. The algorithm is pretty simple. You compute a rectangle around the gesture and then a tic-tac-toe grid of crossing lines. You count the number of times the stroke crosses lines and compute a feature encoding. A dictionary lookup of the encoding produces the appropriate match, if there is one.
Dumky has written his own recognizer in C# by examing the Palm Graffiti recognizer. It's not identical to the Ledeen-Teitelman recognizer but they rely on the same type of feature extraction. Graffiti is used primarily for recognizing letters and numbers, not gestures. Perhaps with the availability of TabletPCs and larger-screen PDAs, gesture-based input will become more common.
Dumky has written his own recognizer in C# by examing the Palm Graffiti recognizer. It's not identical to the Ledeen-Teitelman recognizer but they rely on the same type of feature extraction. Graffiti is used primarily for recognizing letters and numbers, not gestures. Perhaps with the availability of TabletPCs and larger-screen PDAs, gesture-based input will become more common.
Javadoc commenting guidelines
I've been on two large Java projects where we've tried to keep our Javadoc clean and useful. Not everyone appreciates the utility of Javadoc so the results are often inconsistent and less useful than they ought to be. This entry on Hacknot has a good list of guidelines on how to improve Javadoc commenting. (Hacknot reference via Ned Batchelder)
.NET Delegates
Delegates are a .NET framework feature that allows treatment of methods as first-class objects. They are more than just function pointers as this entry on Dumky's blog points out. In Java terms, a C# delegate is dynamically creating an interface that declares a single method. C# uses delegates rather than Listener interfaces to implement most of its event handling. O'Reilly Network has an article on how to build a Java implementation of delegates using Dynamic Proxies.
September 11, 2001
Two years ago today I was driving to a 9am doctor's appointment. As I was about to park my car, there was a report on the radio that a commuter plane had stuck the North Tower of the World Trade Center. They had few details beyond the fact that there was visible smoke at the top of the building. It sounded like an accident. A half-hour later, my appointment was over and I got in my car. I flip on the radio. The other tower has been struck, it's obvious that this is a terrorist attack. I had a business appointment in Cambridge at 11am and needed to drive there. While driving and listening to more reports on the radio, I notice pedestrians walking down the sidewalks. I think to myself, "The world just became a scarier and more dangerous place and these people have no idea".
We all remember where we were and what we were doing that day. And we all know the rest of the story.
There have been, thankfully, few events in my life that have scared me as much as that day two years ago. The sense of horror and shock has still not completely gone away.
Recently I read Bruce Schneier's excellent book Beyond Fear: Thinking Sensibly About Security in an Uncertain World. The book describes the elements of real-world security measures and how to evaluate them. The events of 9/11 are described early in the book and used throughout when discussing various aspects of security. Oddly enough, I feel somewhat better after reading this. I feel like I can make better sense of real and perceived risks as well as tradeoffs involved in security measures.
We all remember where we were and what we were doing that day. And we all know the rest of the story.
There have been, thankfully, few events in my life that have scared me as much as that day two years ago. The sense of horror and shock has still not completely gone away.
Recently I read Bruce Schneier's excellent book Beyond Fear: Thinking Sensibly About Security in an Uncertain World. The book describes the elements of real-world security measures and how to evaluate them. The events of 9/11 are described early in the book and used throughout when discussing various aspects of security. Oddly enough, I feel somewhat better after reading this. I feel like I can make better sense of real and perceived risks as well as tradeoffs involved in security measures.
Wednesday, September 10, 2003
Java class file contents and JEFF
Here's an interesting technical paper analyzing the content of typical Java class files. Note: the paper is in Postscript format. You can grab a copy of Ghostscript to read it. Here are some interesting items in the paper:
- On average, 32% of a class file is inessential information, such as the name of the source file or tables associating offsets into the bytecodes to line numbers in the Java source code. A class file can be reduced to 70% of its size and stay perfectly functional.
- On average, the bytecodes take only 12% of a class file and only 18% of a class file stripped of superfluous content.
- On average, the constant pool accounts for a whopping 61% of a class file.
I know where you are, maybe...
I was downloading a software package and noticed that the download page made reference to the MaxMind GeoIP: location service to help locate a download mirror site that was near my location. This service says that it can give you information about the country in which an IP address resides. Looks likes it's really just a database with ranges of IP addresses and which country they reside in. Given the fluid nature of the Internet, dialups via ISPs, routing through proxies, etc. this doesn't seem particularly accurate.
In constrast, the location capabilities of cell phones via the Enhanced 911 (E-911) mandate will make it trivial to locate someone when their cell phone is on. Sounds cool for emergencies. Since it's a GPS it would also be useful for getting directions, locating nearby stores, etc. but it also sounds like it would make it too easy to keep tabs on your location . I hope there will be a way to block this information when you want your location to be private -- something like the way that you can block caller-id by dialing *67 before a call. (Note: cell phone records contain information about which towers were used during a call but the E-911 system will be much more accurate).
In constrast, the location capabilities of cell phones via the Enhanced 911 (E-911) mandate will make it trivial to locate someone when their cell phone is on. Sounds cool for emergencies. Since it's a GPS it would also be useful for getting directions, locating nearby stores, etc. but it also sounds like it would make it too easy to keep tabs on your location . I hope there will be a way to block this information when you want your location to be private -- something like the way that you can block caller-id by dialing *67 before a call. (Note: cell phone records contain information about which towers were used during a call but the E-911 system will be much more accurate).
Tuesday, September 09, 2003
Inside every API is a programming language struggling to get out
This entry in Erik Meijer's blog discusses an interesting programming language design issue: APIs versus language constructs. As he says,
Like it or not, an API is a language extension. As Erik says, it only really makes sense in the context of a programming language. The hard part is deciding which APIs or patterns to upgrade into first class language constructs. For example, Sun is adding support for an enhanced "for" loop to Java. It may just be "syntactic sugar" but it will make APIs that use Iterators and generics that much easier to express. (Via Lanbda Blog)
"APIs and programming languages form a symbiosis; an API only makes sense in the context of a programming language and a programming language becomes interesting if it has access to a rich set of APIs"For programming languages that have very mutable syntax such as Lisp, it's relatively easy to feel like you're extending the language as you create new APIs. In more conventional languages such as C++ or Java, there's little that you can really extend. You rely instead on programming idioms (such as the usage of Iterators in Java). Usage of COM in C++ suffered because the concepts in COM didn't really match the object model of C++ You could "sugar coat" COM somewhat by using templates and ATL, but Microsoft ended up extending C++ to make COM somewhat more usable.
Like it or not, an API is a language extension. As Erik says, it only really makes sense in the context of a programming language. The hard part is deciding which APIs or patterns to upgrade into first class language constructs. For example, Sun is adding support for an enhanced "for" loop to Java. It may just be "syntactic sugar" but it will make APIs that use Iterators and generics that much easier to express. (Via Lanbda Blog)
Programming Language Naming Patterns
Related to my entries on the etymology of the names PHP and Forth, here's a list of Programming Language Naming Patterns and the origins of a large number of program language names. I don't think it's 100% accurate. My understanding was that the name LISP came from "List Processing". (Via Lambda Blog)
Monopoly money
On October 9th (Columbus Day), the Federal Reserve will start distribution of a new colorful $20 bill. The new $20 contains "subtle green, peach and blue colors" in the background. New versions of the $50 and $100 bills will follow. Different colors will be used for different denominations. I guess we'll have to stop making fun of foreign currency now. .
The colors are another mechanism to make US currency harder to counterfeit. Most conterfeit money found in the US is produced on inkjet printers and is easy to catch. But back in the 1990s, countries such as Iran and Syria had access to the same intaglio presses used to produce the older US bills. These counterfeits were of such high quality, they're called Supernotes.
.
The colors are another mechanism to make US currency harder to counterfeit. Most conterfeit money found in the US is produced on inkjet printers and is easy to catch. But back in the 1990s, countries such as Iran and Syria had access to the same intaglio presses used to produce the older US bills. These counterfeits were of such high quality, they're called Supernotes.
GNOD: Global Network Of Dreams
GNOD is a website for recommending movies, music, books, authors and other web sites. The idea seems pretty similar to Firefly Networks "collaborative filtering" software. There's not really much info on the GNOD web site to get a sense of how it works internally.
You can type in the title of a movie, for example Unbearable Likeness of Being and it displays a map of other movies that you might enjoy. It has a somewhat curious data set right now. I can't imagine how Robin Hood: Men In Tights would end up being recommended for someone who enjoyed the film adaption of Kundera's novel. GNOD also supports a recommendation approach very similar to Firefly. It asks you to list three things you like (e.g. books) and then asks you about a set of other books and whether you like them or not or have no opinion. (Via Pete)
You can type in the title of a movie, for example Unbearable Likeness of Being and it displays a map of other movies that you might enjoy. It has a somewhat curious data set right now. I can't imagine how Robin Hood: Men In Tights would end up being recommended for someone who enjoyed the film adaption of Kundera's novel. GNOD also supports a recommendation approach very similar to Firefly. It asks you to list three things you like (e.g. books) and then asks you about a set of other books and whether you like them or not or have no opinion. (Via Pete)
The Cable Clock
When your day just seems to creep along there's the cable clock. If you're looking for something more industrious, try this one.(Via Metafilter)
Monday, September 08, 2003
Warren Zevon
Warren Zevon passed away on Sunday after a year-long battle with lung cancer. He was only 56. He was one of the wittiest songwriters around with a particularly dark sense of humor. I remember seeing him at a terrific show at the Orpheum in Boston in 1990.
Zevon appeared on David Letterman last year. Not long before, he had been diagnosed with a rare form of lung cancer with only a matter of weeks to live. He talked about his illness and facing death. "From your perspective now, do you know something about life and death that maybe I don't?" Letterman asked. "Not unless I know how much... you're supposed to enjoy every sandwich," Zevon said.
As the show ended, Letterman leaned toward Zevon and said, "Warren, enjoy every sandwich."
Zevon appeared on David Letterman last year. Not long before, he had been diagnosed with a rare form of lung cancer with only a matter of weeks to live. He talked about his illness and facing death. "From your perspective now, do you know something about life and death that maybe I don't?" Letterman asked. "Not unless I know how much... you're supposed to enjoy every sandwich," Zevon said.
As the show ended, Letterman leaned toward Zevon and said, "Warren, enjoy every sandwich."
The Futile Pursuit of Happiness
The title of this article sounds like the caption on New Yorker cartoon. It's a bit misleading. The research it reports on is more positive than the title makes it sound. The findings indicate that we make forecasting errors for both positive and negative events and tend to overestimate how we think they'll affect our lives:
If Daniel Gilbert is right, then you are wrong. That is to say, if Daniel Gilbert is right, then you are wrong to believe that a new car will make you as happy as you imagine. You are wrong to believe that a new kitchen will make you happy for as long as you imagine… You are even wrong to reckon that a cheeseburger you order in a restaurant — this week, next week, a year from now, it doesn’t really matter when — will definitely hit the spot. That’s because when it comes to predicting exactly how you will feel in the future, you are most likely wrong.
(Note: I've used the Google link to access the article so you shouldn't need a NYTimes web account).
Happy Birthday Google!
Google turned five yesterday. This is a "triumph of the nerds" moment. In five years Google has gone from cool geek technology to become the oracle (No, not Oracle). It's the web site we use to answer questions. It's the Hitch Hiker's Guide to the Galaxy expressed as a type-in field on a web page. In fact, "Googling" has become so pervasive that many people have become to ask whether Google has become too powerful. Why look anywhere else, let's ask Google.
Sunday, September 07, 2003
Whale Rider
I watched Whale Rider the other evening. It's the story of Paikea (Pai), a 12-year old Maori girl living in a rural town on the coast of New Zealand. According to the legend of her tribe, their ancestor, Paikea, founded their village after arriving on the back of a whale. From that time tribal chiefs have been exclusively the first born male descendant of Pai's family. Overall a very good film. Good acting all around. The background on Maori culture was very interesting. The cinematography of the New Zealand coastline was dazzling. Keisha Castle-Hughes who plays Pai is excellent.
Another terrific, albeit very dark, film about modern Maori culture is Once Were Warriors. It stars Temuera Morrison as a nasty abusive husband. (He also played Jango Fett in Star Wars 2: Attack of the Clones)
Another terrific, albeit very dark, film about modern Maori culture is Once Were Warriors. It stars Temuera Morrison as a nasty abusive husband. (He also played Jango Fett in Star Wars 2: Attack of the Clones)
Winged Migration
We saw Winged Migration last evening. Simple concept: 90 minutes of birds migrating. But the cinematography is amazing. You are "flying" with the birds. The cameras get up so close that you can hear the birds calling one another and see each body movement, each feather. How the heck did the film makers actually take this astonishing footage? According to the movie press kit, they used a combination of gliders, remote controlled gliders, model helicopters, ultralights, balloons, etc. to get in among the birds in flight. They spent four years making the film. At the end, the credits roll by with hundreds of names of camera men, pilots, location coordinators, etc. It must have been an incredibly complex project to produce.
This isn't a classic documentary. There' s some narration and captions to tell you where the birds are flying and how far a particular species travels but that's about it. There are occasional mini-dramas when a group of birds depart or land but most of the screen time is devoted to this amazing footage of birds in flight. Definitely recommended as long as you don't require humans, dialog and plot in your movie watching experience.
This isn't a classic documentary. There' s some narration and captions to tell you where the birds are flying and how far a particular species travels but that's about it. There are occasional mini-dramas when a group of birds depart or land but most of the screen time is devoted to this amazing footage of birds in flight. Definitely recommended as long as you don't require humans, dialog and plot in your movie watching experience.
Friday, September 05, 2003
Hackity Hackity Hack
Wow, O'Reilly has a whole book series on Hacks. Some of the topics are expected Linux Server Hacks, Mac OS X Hacks, Window XP Hacks, etc. but Hacks books on Amazon, eBay and Google. Huh? And each book is more than 300 pages long. I guess I shouldn't be so surprised. They are probably the three most popular commercial web sites and do offer APIs of a sort (and explicitly so in Google's case).
What's a Professional Programmer, anyway?
I just read an article written by Phil Greenspun about Redefining Professionalism for Software Engineers. He makes some interesting points about what professionalism is all about and how it applies to programmers. His definition has three components: become a skilled practitioner, advance the state of the art and teach others how to improve their skills. Fine goals but I don't believe, as Phil insists, that open source is the "one true way" to achieve this. (And besides, getting someone to pay you to work on an open source project is getting exceedingly difficult these days).
A few resources that can help a new programmer develop as a professional are:
(Robert Reed reference via Ned Batchelder)
A few resources that can help a new programmer develop as a professional are:
- Robert Reed's excellent guide How to be a Programmer. It covers technical and people-related aspects of the profession.
- The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas.
- Code Complete: A Practical Handbook of Software Construction by Steve McConnell
(Robert Reed reference via Ned Batchelder)
More Human Than Human
The Wave tests if the San Francisco mayoral candidates are replicants or not by administering the Voight-Kampff test (from Blade Runner). Pretty humorous. Funniest answers were from Tom Ammiano who realized that the test was from Blade Runner:
TW: You’re in a desert walking along in the sand when all of the sudden you look down, and you see a tortoise, Tom, it’s crawling toward you. You reach down, you flip the tortoise over on its back, Tom. The tortoise lays on its back, its belly baking in the hot sun, beating its legs trying to turn itself over, but it can’t, not without your help. But you’re not helping. Why is that, Tom?(Via Metafilter)Tom Ammiano: That’s interesting. I don’t know. I’m a republican?
TW: Describe in single words, only the good things that come into your mind. About your mother.
TA: Tenderness. Yelling.
Where IKEA gets their product names
IKEA, the Swedish home furnishing retailer has an interesting .product naming scheme. They name products after Nordic names, counties, towns, islands and rivers. For those of us who are unfamilar with Swedish or Norwegian, some of the names come across in English as bizarre. For example, the IKEA Jerker desk. Jerker is a Swedish man's name. Also there's the IKEA Fartful children's desk. Fartful means 'speedy' in Swedish.
A Life of Letters: Matthew Carter
Matthew Carter is a type designer. He designed a number of well-known typefaces such ITC Charter and ITC Galliard. He also worked with Microsoft to design a number of typefaces for screen fonts including Verdana and Georgia. (Yes, some people really hate Verdana but it was designed for readability not "beauty"). Carter was interviewed on The Connection yesterday. One thing I found a little surprising was that when he designs a a new typeface he starts with the lower-case "h" and "o" first. You can listen to the full interview here.
Thursday, September 04, 2003
Blue Fizzle
Two years ago today my last startup, Blue Ripple, stopped "circling the drain" and headed straight down. (And unlike the itsy bitsy spider, never went up again). We failed to raise second round funding and that was that. It was an orderly shutdown compared to most startup failures which was good I guess but a throroughly demoralizing experience otherwise. According to the American Heritage Dictionary, fizzle is defined as:
According to the etymology and word history on the same page, fizzle originally meant "to break wind without noise". My sentiments exactly. Fizzle...
Note: the blueripple.com domain is now owned by Domain Deluxe. Looks like they're just in the business of owning and reselling domain names. There's no pertinent content there now. And don't be confused by the other Blue Ripples out there.
To fail or end weakly, especially after a hopeful beginning.
According to the etymology and word history on the same page, fizzle originally meant "to break wind without noise". My sentiments exactly. Fizzle...
Note: the blueripple.com domain is now owned by Domain Deluxe. Looks like they're just in the business of owning and reselling domain names. There's no pertinent content there now. And don't be confused by the other Blue Ripples out there.
Wednesday, September 03, 2003
Pito Salas
I just discovered that Pito Salas has a blog and he's been steadily adding content over the last few months. I worked for Pito on Lotus Improv. It was his baby from concept to the first release on NeXTStep. I didn't know squat about spreadsheets but Pito hired me anyway. Pito moved on to other projects inside of Lotus while we shipped Improv on Windows. It was kinda cool to do a "mainstream" product that anyone could buy at their local computer store but it wasn't nearly as much fun as the first release. That was a blast.
And what does FORTH stand for?
This is from the Forth FAQ:
I was enamoured with Forth early in my career. The core interpreter and base set of words (aka. functions) is simple enough to write a straight-forward implementation in a few hundred lines of assembler. It's built on a handlful of powerful constructs that make it easy to extend in interesting ways. Unfortunately, that's also a disadvantage. Forth has a reputation as a "write only" language partially due to the fact that it's so easy to write your own dialect of the language. Another stunbling block for many developers is syntax. Forth uses postfix (RPN) notation. I never ended up writing anything substantial in Forth but I did write a simple Forth intepreter in VAX Macro. It was a lot of fun in a very geeky sort of way.
Postfix languages never seem to catch on. Postscript uses a syntax that's similar to Forth. It's a somewhat higher-level language than Forth, entries on the stack are typed and it has a more extensive set of types. An important distinction is that the Postscript langauge is a means to an end. It's really all about imaging. Most of the effort in building Postscript was spent dealing with graphic concepts: fonts, paths, transforms, etc. Plus, not too many people make a living from writing Postscript code (there have been exceptions). It's "just" a printer language.
Actually I'm understating Postscript's applicability. It's been used quite successfully for rendering in windowing systems as well. On NeXTStep, applications could use Display Postscript (DPS) and have the same code that is drawing to a window be used to draw to a printer without any translation. Plus you can take advantage of processing power in the main CPU and render to "dumb" bitmap printers.
A less successful usage of Postscript for display was NeWS (Network/extensible Window System). Display Postscript handled rendering but the windowing system was part of the OS. With NeWS, the entire window system was done in an extended form of Postscript. So unlike DPS where you only concern yourself with Postscript when you need to render something, with NeWS, all of your interactions had to be coded in Postscript as well. You needed to spilt your code into client and server portions written in different languages (Postscript and, usually, C/C++). SGI had a NeWS implementation that I used for a while. It was pretty sluggish and buggy. Since application client code ran in the NeWS server it was fairly easy to crash the display server while debugging your application. Not a lot of fun since all of your windows disappeared when the display server dropped. My experience with NeXTstep and DPS was different. It was a better, faster implementation and display server crashes were exceedingly rare. Perhaps NeWS would have caught on with a better implementation.
"The name FORTH was intended to suggest software for the fourth (next) generation computers, which Moore [Charles Moore, the inventor of FORTH] saw as being characterized by distributed small computers. The operating system he used at the time restricted file names to five characters, so the "U" was discarded. FORTH was spelled in upper case until the late 70's because of the prevalence of of upper-case-only I/O devices. The name "Forth" was generally adopted when lower case became widely available, because the word was not an acronym.".So it's not an acronym and the weird spelling was a side-effect of an OS filename length limitation.
I was enamoured with Forth early in my career. The core interpreter and base set of words (aka. functions) is simple enough to write a straight-forward implementation in a few hundred lines of assembler. It's built on a handlful of powerful constructs that make it easy to extend in interesting ways. Unfortunately, that's also a disadvantage. Forth has a reputation as a "write only" language partially due to the fact that it's so easy to write your own dialect of the language. Another stunbling block for many developers is syntax. Forth uses postfix (RPN) notation. I never ended up writing anything substantial in Forth but I did write a simple Forth intepreter in VAX Macro. It was a lot of fun in a very geeky sort of way.
Postfix languages never seem to catch on. Postscript uses a syntax that's similar to Forth. It's a somewhat higher-level language than Forth, entries on the stack are typed and it has a more extensive set of types. An important distinction is that the Postscript langauge is a means to an end. It's really all about imaging. Most of the effort in building Postscript was spent dealing with graphic concepts: fonts, paths, transforms, etc. Plus, not too many people make a living from writing Postscript code (there have been exceptions). It's "just" a printer language.
Actually I'm understating Postscript's applicability. It's been used quite successfully for rendering in windowing systems as well. On NeXTStep, applications could use Display Postscript (DPS) and have the same code that is drawing to a window be used to draw to a printer without any translation. Plus you can take advantage of processing power in the main CPU and render to "dumb" bitmap printers.
A less successful usage of Postscript for display was NeWS (Network/extensible Window System). Display Postscript handled rendering but the windowing system was part of the OS. With NeWS, the entire window system was done in an extended form of Postscript. So unlike DPS where you only concern yourself with Postscript when you need to render something, with NeWS, all of your interactions had to be coded in Postscript as well. You needed to spilt your code into client and server portions written in different languages (Postscript and, usually, C/C++). SGI had a NeWS implementation that I used for a while. It was pretty sluggish and buggy. Since application client code ran in the NeWS server it was fairly easy to crash the display server while debugging your application. Not a lot of fun since all of your windows disappeared when the display server dropped. My experience with NeXTstep and DPS was different. It was a better, faster implementation and display server crashes were exceedingly rare. Perhaps NeWS would have caught on with a better implementation.
What does PHP stand for?
I'm digging a little into the PHP language so I can do some simple scripts when I rehost this blog. As a programming language and etymology geek, my first question was: what the heck does PHP stand for? According to the FAQ, "PHP is a recursive acronym that stands for: PHP: Hypertext Preprocessor". But wait, there's more -- PHP succeeds any earlier incarnation called "PHP/FI" where PHP stood for "Personal Home Page".
Humorous early software company names
Ned mentioned a type design studio called Underware. Not sure why they call themselves Underware but it reminded me that the original company that developed the Brief text editor was also called Underware (which has a more obvious connection between company and product name). It turns out that there's another editor called Boxer which was also began as a play on words: another style of men's underwear.
A couple others I can recall from the early days of PC software were "Pickles and Trout" and BDS. "Pickles and Trout" developed a version of CP/M for Radio Shack TRS-80s. Can't seem to find any references via Google. BDS stood for "Brain Damaged Software" They wrote a C compiler for CP/M. Most people referred to the compiler as BDS C without necessarily knowing what the acronym stood for. Kind of like KFC trying to hide the fact that "Fried" is part of their name.
A couple others I can recall from the early days of PC software were "Pickles and Trout" and BDS. "Pickles and Trout" developed a version of CP/M for Radio Shack TRS-80s. Can't seem to find any references via Google. BDS stood for "Brain Damaged Software" They wrote a C compiler for CP/M. Most people referred to the compiler as BDS C without necessarily knowing what the acronym stood for. Kind of like KFC trying to hide the fact that "Fried" is part of their name.
Concurrent collections classes
Java has gone through some evolution in the type of concurrency support available in its Collection classes. In early JDK releases only synchronous access was supported. This added overhead even when you didn't need it. The Collection classes added in JDK 1.2 made synchronous access an option but the implementation was coarse-grained using a single lock for all access to an object. This works in most cases but doesn't scale very well with lots of threads. This article describes the ConcurrentHashMap class that will appear in JDK 1.5 which can allow concurrent readers and writers. For multi-threaded servers applications, the improvement in scalability can be substantial. The article also mentions CopyOnWriteArrayList which can be incredibly useful in event notifications. And you don't have to wait for JDK 1.5. You can use these classes and lot more in Doug Lea's excellent util.concurrent package.
Note: evolution of class libraries is tricky and I think Sun has done a laudable job in keeping existing code from breaking in newer releases One negative consequence of evolution is that a lot of Java developers don't realize the tradeoffs among the different classes. I still see newly written code using Hashtable and Vector when HashMap and ArrayList would be better choices. Likewise, we'll probably see HashMap in use for years after ConcurrentHashMap becomes available and would be a better choice. Maybe by then Eclipse will have evolved to a level where it can look for concurrency access patterns of use and recommend that you use the newer classes and interfaces. That would be cool. A realization of the kind of tool described in The Programmer's Apprentice
Note: evolution of class libraries is tricky and I think Sun has done a laudable job in keeping existing code from breaking in newer releases One negative consequence of evolution is that a lot of Java developers don't realize the tradeoffs among the different classes. I still see newly written code using Hashtable and Vector when HashMap and ArrayList would be better choices. Likewise, we'll probably see HashMap in use for years after ConcurrentHashMap becomes available and would be a better choice. Maybe by then Eclipse will have evolved to a level where it can look for concurrency access patterns of use and recommend that you use the newer classes and interfaces. That would be cool. A realization of the kind of tool described in The Programmer's Apprentice
Tuesday, September 02, 2003
Comments again
Enetation seems seriously broken now. I'm giving Squawkbox.tv another try. Let's see how this works out.
Monday, September 01, 2003
Krzysztof Kieslowski's The Decalogue
I just read that a "Special DVD Edition" of Kieslowski's The Decalogue has just been released. I've been waiting to get a chance to see this. It was originally shown on Polish television as 10 one hour dramas. Kieslowski's work is hard to describe. It's just excellent, complex, emotional film-making. Go rent a copy of The Double Life of Veronique. If you enjoy it, then go rent Three Colors Trilogy. Each of the three films in the trilogy is terrific on its own.
Processing
This looks promising. Build spacey media with Processing which can run as client-side Java in a browser. The software kit isn't downloadable just yet but the samples include source and it looks like fun. Here's a sample that models a Zombie Infection. (Via Metafilter)
RSS 0.92 Feed