Skip to main content

The value of a name

Posted by daniel on January 19, 2005 at 11:18 AM EST

Do we benefit from a common vocabulary?

In Projects and Communities, John Vlissides talks to Dev X about the history of the GoF book and the possibilities of a second edition. He explains "design pattern's two-pronged benefit as a vehicle for standardization."

In addition to promoting reuse of design, "design patterns engendered a standard vocabulary that enabled architects to discuss design at a higher level. Vlissides now believes this standard vocabulary is the most valuable benefit of design patterns and its main contribution to OO programming. Design patterns, he said, 'enable a discourse that wasn't possible previously.'"

The power of a name. Many proponents of patterns point to how common words like "Visitor", "Observer", "State", and so on are included in every day conversation among programmers. Eugene Wallingford blogs about the value in the idea of Name It. In this new year he has resolved to helping students find the name for what they can and cannot do:

" Often, people can better accept their condition when it has a name. Knowing that what they feel is normal, normal enough to have a name and be a part of the normal conversation, frees a person from the fear of not knowing what's wrong with them. Sometimes, there's nothing wrong with you! And even when there is, when the name tells us that something horrible is wrong, even then a name carries great power. Now we know what is wrong. If there is something we can do to fix the problem, we have to know what the problem is. And even when there is nothing we can do to fix the problem, yes, even then, a name can bring peace. 'Now I know.'"

If I ever return to teaching, I hope to be half the teacher that Eugene Wallingford is - and yet there is a downside to naming. A physicist friend of mine described the response to his question about the quantity Volume divided by Mass. What would this quantity represent. Many of the students answers were nonsense. He asked another section of the same class about Volume divided by Mass. They quickly responded that this was just density. They knew its name. For some, they also knew what it meant, but for many the act of naming it was sufficient.

Update: One reader was kind enough to correct my mistake in the previous paragraph where I should have said "He asked another section of the same class about Mass divided by Volume. They quickly responded that this was just density." That is what I meant to say and I thanked the reader for the correction and told him that was exactly the point. His reply was really quite wonderful. He wrote "I wasn't so sure about that. There is a difference between knowing the jargon for some concept but not understanding what it means and applying jargon incorrectly. You seemed to me to be trying to concentrate on the former while, possibly unintentionally, giving an example which matched the latter."


This year's T-shirt contest for JavaOne is open. In today's Weblogs James Gosling writes "It even has its own web site, at https://tshc.dev.java.net/. Get some geek fame by figuring out a way to hurl a t-shirt into the audience during the general sessions at the 2005 JavaOne conference.

When you're ready for something different today, follow the links from Manoel Lemos' blog The sound of JAVA. Take a break and have some fun.... He writes about his past presentations of " a few multimedia JAVA projects. One of them was the RABISCO, a project from the Interdiciplinary Nucleous of Sound Study (NICS) of the State University of Campinas (UNICAMP)."

Eitan Suez has Thoughts on Gosling's "Sharpen the Axe: the Dark Side" He believes "that many developers go through a nerve-racking decision making process at the start of every new project: how much work is this project going to require? What resources (people, budget, time) are at my disposal?"


In Also in Java Today , Roger Sessions writes "It’s easy to transform objects into components and Web services, but how do we know which is right for the job?" In Fuzzy Boundaries: Objects, Components, and Web Services , he writes "When both the entity and the client are located in the same process, the relationship is characterized as an object relationship.[..] When the entity and the clients are located in different processes, then the environment becomes the defining characteristic. When the environment is the same for the client and the entity, the relationship is characterized as a component relationship. [..] When the environment is different for the client and the entity, the relationship is characterized as a Web service relationship."

When it comes to parsing an XML document with XPath, Java developers can choose between JDOM and the java.xml.xpath package provided in J2SE 5.0. In Parsing an XML Document with XPath, Deepak Vohra takes a look at parsing an XML document with each of these API's, so you can decide which one is right for you.


Do you have a hard time figuring out which track to submit your JavaOne talk in? In today's Forums, david_hall writes "I had about 500 people last year at a session on Generics and Functors, and would like to do a follow up BOF based on what I've learned/developed since then. The problem is that last year I submitted it on the Desktop track and I'm not sure that its the most appropriate place (although my examples tend to be desktop related since that's where my background and interests lie)."


In today's java.net News Headlines :

Registered users can submit news items for the java.net News Page using our news submission form. All submissions go through an editorial review before being posted to the site. You can also subscribe to thejava.net News RSS feed.


Current and upcoming Java Events :

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.


Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.

Do we benefit from a common vocabulary?