Will the real whiteboard pattern stand up?

The OSGi Alliance white paper, "Listners Considered Harmful: The "Whiteboard" Pattern", describes the whiteboard pattern as:

...Instead of having event listeners track event sources and then register themselves with the event source, the whiteboard pattern has event listeners register themselves as a service with the OSGi framework. When the event source has an event object to deliver, the event source calls all event listeners in the service registry.

Remarkably, the event source is not registered with the framework as a service. This makes bundles using the whiteboard pattern significantly smaller and easier to implement. The inter-bundle dependency between the event source and the event listener is handled by the framework and requires almost no code in the event source and event listener bundles.

The SpringSource Tool Suite tutorial on the whiteboard pattern describes it similarly,

The whiteboard pattern uses the service registry to decouple the interested parties. If an observer wishes to listen to events, the observer simply publishes a service that implements an agreed listener interface. The subject (or event producer) simply sends events to all registered services implementing the listener interface at the time the event is generated.

Instead of advertising the subject, and keeping state about all known observers in the subject, we advertise the observers and use the service registry itself to keep track of them.

However, an article on TheServerSide.com describes the pattern slightly differently:

Basically, the whiteboard pattern is this: a content provider registers itself into the OSGi service registry. A content consumer regularly polls the registry for consumers of the content provider type, and then calls each one in turn.

Strangely, the example code in the white paper shows the same style as TheServerSide's article: a ClockManager registers a Clock object as an OSGi service (under a ContentProvider interface). Subsequently, DisplayManager thread periodically polls the ContentProvider services and displays the content.

I would think that a straightforward implementation of the description of the whiteboard pattern would have the Displays register ContentListener interfaces, and have the Clock objects periodically publish the time to those listeners.

On the other hand, that straightforward implementation would likely be wrong. Since the display is only interested in the current state when it is being updated (the window is visible, the LCD is turned on, etc.), the implementation as shown in the paper's example avoids having the clock update the displays when they cannot do anything with the information. On the third hand, the displays could unregister their services when the window is hidden or the LCD powered off. This avoids having an extra polling thread per display.

The SpringSource tutorial wisely uses a completely different example which does seem to follow the description.

Finally!

InformIT: Is Computer Science Dying? : Computer Science and Telescopes

Finally! Someone who seems to understand that computer science is actually a subject in its own right!

In attempting to describe computer science, Edsger Dijkstra claimed, "Computer science is no more about computers than astronomy is about telescopes." I like this quote, but it’s often taken in the wrong way by people who haven’t met many astronomers. [Hanging around observatories,] I learned a lot more about optics than I ever did in physics courses at school. I never built my own telescope, but a lot of real astronomers did, and many of the earliest members of the profession made considerable contributions to our understanding of optics.

There’s a difference between a telescope builder and an astronomer, of course. A telescope builder is likely to know more about the construction of telescopes and less about the motion of stellar bodies. But both will have a solid understanding of what happens to light as it travels through the lenses and bounces off the mirrors. Without this understanding, astronomy is very difficult.

David Chisnall concludes,

Computers are part of everyday life for a lot of people. Even discounting desktop computers, most people interact with a large number of computing devices every day. This trend has lead to a more algorithmic view being taken of a lot of processes, and computer science is essential in building these devices.

The decline in computer science applicants is likely to continue for a while. Computer science is no longer a buzzword-compliant "get rich quick" subject, and people (outside the BCS) are starting to realize that it’s not a vocational software development degree course. This realization is likely to be good for the subject in the long run, because it will remove many of the students who never should have chosen that field in the first place. Physics has also seen a decline in applicants in recent years, and no one is claiming that it’s dying and needs to cater more to teaching people to be second-rate engineers, rather than first-rate scientists.

The definition of "Web Services"...

From Designing Web Services with the J2EE 1.4 Platform: JAX-RPC, SOAP, and XML Technologies:

What are Web Services

For example, the World Wide Web Consortium (W3C) organization, which establishes the standards for
Web services, defines them as follows: “A Web service is a software system identified by a URI whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols.”

It then goes on with:

A simpler definition, and perhaps more useful, might be: “a Web service is a software application, accessible on the Web (or an enterprise’s intranet) through a URL, that is accessed by clients using XML-based protocols, such as Simple Object Access Protocol (SOAP) sent over accepted Internet protocols, such as HTTP. Clients access a Web service application through its interfaces and bindings, which are defined using XML artifacts, such as a Web Services Definition Language (WSDL) file.”

I have no further comments on web services at this point.

[Later.] I was wrong. The Sun Java System Application Server Platform Edition 9 Java EE Tutorial is 12 PDF pages and consists entirely of the following sentence:

The Sun Java System Application Server 9 Platform Edition is fully compatible with the Java EE 5.0 Tutorial.

Apress books

Has anyone else noticed that many of the books from Apress are really not very good?

I was just reading Beginning JavaScript with DOM Scripting and Ajax (left by the previous resident of my cube), and discovered the following code in a section on "Changing Attributes of Elements" in the DOM:

var firstLink=document.getElementsByTagName('a')[0];
if (firstLink.getAttribute('href') =='search.html')
{
firstLink.setAttribute('href') = 'http://www.google.com';
}

This code immediately follows a paragraph saying,

The DOM specifications provide two methods to read and set attributes---getAttribute() and setAttribute(). The getAttribute() method takes one parameter---the attribute name; setAttribute() takes two parameters---the attribute name and the new value.

On the one hand, the code has clearly been formatted by a non-programmer, someone who has no particular experience with reading or writing code. (Of course, the paragraph doesn't sound like it was written by someone with no particular experience reading or writing.) On the other hand, it's just wrong. Not only does it not match the text, it is just wrong.

Similar problems plagued the Apress O'Caml book, which had simply atrocious code examples and was very poorly written.

I have heard many good reviews of the Apress Common Lisp book (and have a copy on my to-read shelf along with a couple of other Apress books which I have not noticed being so bad). But after these examples, I am dubious.

[Edit: added the missing "not".]

Functional Programming in the ACM CS Curriculum

Lambda the Ultimate recently had a discussion on a proposal to to include functional programming (defined somehow) in the ACM's Computer Science curriculum (Functional Programming in the ACM CS Curriculum). Tim May posted a comment comparing the situation in Computer Science education to the split between Physics and Engineering.

Specifically, he asked, "How much theory and "not useful" stuff (like FP, type theory, theorem provers, etc.) to include in a CS major is a lot like the debate about whether engineers ought to study relativity and quantum mechanics, or just stick to the more useful stuff like circuit diagrams, strength of materials, gas equations, and such." He further went on to describe,

Most of my programmer friends here in the Valley (Silicon) are hip-deep in things like "the LAMP Stack" (the package of interrelated tools like Linux, Apache, MySQL, and Python/Perl/PHP, hence the name). The Web 2.0 companies want programmers with skills in Java, Javascript, AJAX, Ruby, Rails, Python, GWT (Google Web Toolkit), and the who alphabet soup of current stuff. Similar alphabet soups, with different names, 10 years ago, 20 years ago, etc.

Other comments included suggestions for various forms of "vocational education" programs that would not necessarily include things like functional programming, but would focus primarily on the alphabet soup of currently-desperately-needed skills.

Now, I have been a professional programmer for nearly twenty years. (And if you are looking for a career-limiting move, that is a decent one.) I have a Ph.D., not an M.B.A, but my interest in Computer Science education is primarily related to programming professionally, not necessarily producing research. I have also been through more acronym cycles than I would really like to think about.

Given that background, I have a few points I would like to make about the proposal and discussion.

• I am given to understand that the half-life of a programmer is about five years. In other words, most of Tim's programmer friends are not likely to be around for the next set of acronyms. With this in mind, industry's fascination with alphabet skills is understandable and programmers really are disposable, as apparently some versions of management would like. Further, the vocational school of CS education has some very strong points. The system trains in the skills it needs now, then in a few years it trains in the skills it needs at that point; if the same people happen to be learning the skills, well, good on them. But that is hardly the point.
  
  On the other hand, there are consequences. Essentially all software is built by people with vocational training and less than two years' experience. (C.f. my traditional post-interview joke about one year of experience repeated ten times.) Most development systems have essentially no institutional or personal memory. And there is certainly no reason to worry too much about maintenance; by the time the cruft gets too deep to manage, if the technology is not completely passe then it will be someone else's problem.



• There is essentially one programming paradigm taught today: object-oriented programming. Well, two; most object-oriented systems are procedural at their foundations with objects added for larger-scale structure. And if all you have is a hammer and a screwdriver, every problem is going to look like a threaded nail.
  
  There are a number of other paradigms available. For one, real procedural programming, on its own and without the somewhat sleazy, ought to be doing something else feeling. For another, logic programming, and another, constraints, and automata, and concatenative. Oh, and functional. Of these, the one different-ish paradigm that has achieved some level of general purpose is functional programming. If you consider it worthwhile to have different ways of looking at a problem in order to find the best solution, then teaching a functional approach might be useful.



• Teaching every subject in Java might be the most efficient way to create graduates who have some experience in every subject, but short-term efficiency does not necessarily equal long-term good. And if the topic really is professional programming, those undergraduate years really are short-term.



• Some of us are under the possibly delusional impression that "theory" such as functional programming, types, and several other "academic" subjects are more like the strength of materials and gas equations for engineers, rather than relativity and quantum mechanics. Knowledge of basic programming language theory (something like Essentials of Programming Languages for a specific instance), for example, is a basic fundamental to successful programming.



• At some point, and at some level, I do find the "just teach them what they need to know to get a job" ideal offensive.