Sharepoint and Wiki

How do you feel about SharePoint? [<-- edit this Wiki page because it's easier than pointing you to a SharePoint page!] Not long ago the product was being considered a Wiki-like replacement.

My limited assessment time so far tells me I'd rather have a Wiki or a Bliki with perhaps a few small thought-out additions.

Using SharePoint results in about a 10x decrease in effectiveness for similar goals. The threshold for just ignoring a tool for me is about 2-3x decrease. I'll use SharePoint because I have to in some cases. But I am saddened that it's just there because it's from MSFT, as opposed to being there as a result of an evaluation.

Corporations don't get Wiki by and large. They're too simple to be understood in an evaluation.

Benefits of the California Experience

From Harry Shearer...

Having every phase of the campaign, from deciding to run to fund-raising to debates to voting, be compressed into a mere eight weeks may turn out to be a fine advertisement for a radical shortening, on the British model, of American election cycles. Don't bother to thank us in California, we're always working on your future.

Video Conferencing vs. Video Applications

When it is hooked to his Mac, Zeedar can use the camcorder as a webcam for video conferencing. But when his TiVo is plugged into the camera, Zeedar can broadcast pay-per-view soccer games to others.

"It's very cool," said Zeedar. "He can watch my soccer channels from his home. Or anywhere, really."

I see a lawsuit on the horizon.

Past that horizon though are video applications. This matches what I experienced when I was developing video conferencing systems about ten years ago.

The big lesson was that people don't want to look at talking heads. They think that is cute, then collapse the video window and get on with the meeting.

People do want to use the video for applications. The primary one used to be to detect "presence". Of course video is not necessary for that today, but it was a convenient mechanism back then. Other applications include sharing some information that is physically not "in" the computer. With better 3D shape recognition watch out.

As video (and video editing BTW) becomes ubiquitous new applications like Zeedar's will change business models and improve communication. "Pure" video conferencing will fall by the wayside though.

Symbol Grounding

Jon Udell writes about RSS, RDF, and XML in general...Stefano's formulation suggests to me that the troubled relationship between RSS and RDF may have been a red herring all along. Either we do or don't need some higher-order model to manage mixed namespaces sanely. Nobody knows yet. That the question arose in the context of RSS may simply have been an unfortunate historical accident -- RSS happened to be a likely candidate for the necessary large-scale experimentation, and got caught in the crossfire...

Shouldn't we then substitute XML for RSS 2.0 in that sentence, and say there is no consistent way to interpret material from other namespaces in any XML document, period?

Shouldn't we then say, there is no reason to create any mixed-namespace XML document that is not RDF?

This is beyond RSS, beyond RDF, even beyond XML.

This is known as The Symbol Grounding Problem.

Namespaces allow you to create unique (enough) symbols. There is no consistent way to interpret them. All XML-based standards should fully support namespaces. The minimum acceptable standards should support distinguished symbols from among various standards.

What those mixtures "mean" in any specific context will be, well, context dependent. All we can hope for from XML alone is an arrangement of symbols. Whoever tells us of the arrangement will also have to tell us how to interpret the arrangement.

Seven Paradoxes of Object-Oriented Programming Languages

David Ungar is giving a keynote at OOPSLA 2003 on the Seven Paradoxes of Object-Oriented Programming Languages. He writes...

Many of these assertions seem nonsensical, misguided, or just plain wrong. Yet, a deeper understanding of these paradoxes can point the way to better designs for object-oriented programming languages.

Apparently this will be a worthy companion to Guy Steele's keynote on growing a language in 1998. I'd like to see their respective points integrated. Growing a language will have varying results depending on where you begin. The beginning and the growing have to respect the paradoxes.

• Because programming languages, development environments, and execution engines are intended for both people and computers, they must both humanize and dehumanize us.
• Adding a richer set of concepts to a programming language impoverishes its universe of discourse.
• Putting a language's cognitive center in a more dynamic place reduces the verbiage needed to accomplish a task, even though less information can be mechanically deduced about the program.
• The most concrete notions are the most abstract, and pursuing comfort or correctness with precision leads to fuzziness.
• Although a language, environment, and execution engine are designed for the users' minds, the experience of use will alter the users' minds.
• Object-oriented programming has its roots in modeling and reuse, yet these notions do not coincide and even conflict with each other.
• A language designed to give programmers what they want may initially succeed but create pernicious problems as it catches on. However, a language designed to give programmers what they really need may never catch fire at all

Transaction Manifesto

I attended a lecture by Maurice Herlihy on the "Transaction Manifesto". The paper on his site called "Software Transactional Memory for Dynamic-sized Data Structures" reflects the same ideas. This was an interesting talk and the rest of this post explains my interest. Moreover I've now added Herlihy to my list of interesting CS thinkers based on a number of papers and software systems available at his site.

The talk was more of a plea to implement a transaction mechanism in hardware. The argument is that "compare and swap" and similar read-modify-write instructions are too low level.

"Too low level" means there is a lot of complexity in the software between the CAS and the mechanisms that programmers desire. The suggested instructions would operate on more than two memory locations and the locations would not necessarily be close to each other.

The ideas are derived from database concurrency mechanisms, i.e. simple transactions with a begin, some instructions, and a commit or rollback. Essentially this treats RAM like a simple database.

A couple of thoughts came to mind:

• Combine these kinds of instructions with battery-backed RAM and you've significantly simplified the implementation and improved the performance of database mechanisms.
• Next, going back to the discussions around virtual machines this past week, this level of concurrency control should at least show up at the virtual machine level. Why emulate a 1970's instruction set?

Much effort is spent ignoring or recreating lessons learned in the database community. Apparently in hardware as well as software. Alan Kay has wondered why Moore's Law, although wildly accurate and beneficial, has not translated more proportionately into software improvements. Here is an example.

Tech Sector or Taliban?

I'm not sure what this means, when joining the Taliban is more attractive than working in the tech sector.

Service Orien... what?

Service Oriented Architecture is the thing, I guess. But I just found myself wondering when the OS vendors are going to make it easy to install new services. It's a mystery unless you have something like the Erlang OTP running.

Any idea?

It's the content that counts

John Robb asks... isn't The Register just a poorly formatted weblog?

Good point. I personally care about...

1. Content
2. Connections
3. Presentation

Weblogs, Wikis, Pages. If it has useful information and I can find it and make sense of it, it's good to me.

Science Matters

There's a discussion on /. about non-professional books for science and math.

Going back a few years the book Science Matters is a really good, broad, but short and readable-on-a-beach survey of science. Just enough of basic science to keep you out of trouble.

Transformation, JIT, and Security

I'd like to elaborate on the interesting ways Kelsey's transformation approach addresses the following features of virtual machines (from Ted Leung).

"Virtual machines get you portability, the ability to do JIT compilation (although this could be done in native code apps), and security (via sandboxes, etc)."

Portability Kelsey's approach gets you portability to any low level instruction set. Language providers translate to a high level intermediate language. In his case this is Scheme, which is essentially the call-by-value lambda calculus.

Only one programmer has to provide the translation to any specific instruction set, whether it is for a virtual machine or actual metal. Everyone else rides for free.

JIT The intermediate language can be passed around (in a concise format such as the one used by SISC) until such time as it makes sense to transform it into a specific low level instruction set. This has the benefit of delaying the commitment of target architecture longer than a virtual machine architecture provides. Specific distributed objects could be migrated to some unspecified target at run-time and compiled to efficient code, along the lines of Kelsey, et al.'s Kali Scheme.

Security This is the most interesting test of all of the high-level transformation approach. Basing the intermediate form on function application is a beneficial form of security. The high-level model of computation can be analyzed and/or encapsulated more effectively than a low level byte code.

Low level virtual machines are an undesirable model for security. Kelsey's mate Jonathan Rees describes how this alternative works in his and Kelsey's implementation of Scheme.

Binary XML == gzip?

I would venture that the resource constrained platforms are going to be passing relatively small documents anyway. Even the more capable systems should be passing multiple small documents instead of huge documents.

Let's just use gzip.

Quote...

As predicted by Dick Cheney on le show, the Dr. David Kelly story has slipped from America's journalistic radar. But it's still big news in the UK, as is the subsequent war between Tony Blair's government (backed by Rupert's newspapers) and the BBC. I have become a believer in reincarnation: Spiro Agnew is alive and working for Tony Blair, and, in this country, Dr. Fred C. Schwarz (of the Christian Anti-Communism Crusade) has come back as a leggy blonde anorexic.

The 64-bit Question

James Robertson asks the 64-bit question for Smalltalk.

Implementing dynamic languages with 64-bit words always had an appeal to me for this reason:

You can encode 64-bit floats as literals. Everything else can be encoded within a NaN. The result is that arrays of large floats are more efficient in space and time, enabling more efficient analytical computing. You can also encode more information in an immediate object, like characters with styles, full 32-bit integers without shifting tag bits, etc.

Jython

I am beginning to believe this sincerely. Note that it does not say "only weapon", but it does say "most compelling"...

Jython, lest you do not know of it, is the most compelling weapon the Java platform has for its survival into the 21st century

SOAP for Lisp at last

Franz now has a SOAP implementation for Common Lisp. Great news.

"When I last looked at SOAP it was annoyingly complex. But that doesn't mean it's not important..."

What assumptions are *you* making right now?

Perl 6 looks to be delivered on the Parrot virtual machine, which looks to be more and more suitable as a target for the full Scheme language.

If the goal is truly to provide a universal base for executing any language then toss out the virtual machine altogether. Or at least abstract it away for language providers.

Don't make them twiddle with bits just because they implement "compilers". Let them simply translate to another higher level language, as Richard Kelsey demonstrated well over ten years ago!

We (the industry) seem to be stuck in a virtual machine rut. Has anyone asked why that's a good idea?

My track coach in high school told me what "assume" means 25 years ago. We base soooo much on unproven assumptions in this industry.

"Perl 6 to Scheme. Come in, Scheme."

Multiple Canonical Models: Databases or Messages?

Martin Fowler urges the data people and messaging people to talk, but not to define a single model.

This makes sense whether you are talking about enterprise databases or enterprise messages. I would add two points. The final one, if you want to cut to the chase, is addressed pretty well by Cutter's Doug Barry.

The first is that although enterprise models are not easily "big designed upfront" there are proven techniques for supporting their emergence. The best I know of comes from Ralph Kimball, who I've written about before in the context of enterprise integration.

The other point I would add is that Martin is really addressing at least two significant issues. In addition to the perils of enterprise modeling, he's made an implicit point about messaging and databases. I'm not going to put words in his mouth but he could have pointed to his peers efforts to illustrate what he means by enterprise messaging.

I am not sold on the idea of general messaging. There are special cases where a high performance message product makes sense, e.g. broadcasting large volumes of financial information on a trading floor is the motivating example.

In the general case, messaging is just too much like a crippled database that assumes the consumer is not the provider. You end up with an additional product and all the associated costs. I think there is a lot of room for improving 80 percent of the cases a relational database is applied to, but not at the expense of an entirely new and yet severely limited product like messaging. (Hint: every messaging product has some kind of simple persistence mechanism you can't get to in a general way. Why?)

I would choose either low cost databases for Martin's integration scenarios, or, more ideally, a simple XML-based tuple space-like database. Either approach can be used in a myriad ways without assuming the consumer is not also the provider.

Doug Barry kind of addresses this issue in a Cutter report. He is a fellow traveller from the Object Oriented Database market. A full OODB is overkill. So is a full relational database, but at least they are commodity and not so esoteric.

This second point is we need simpler database products rather than messaging products.

Less Code == More Productivity

Via Lambda the Ultimate we see Don Box wanting less code to espress a simple concept. This makes sense and corresponds to the conventional wisdom that programmers can get X lines of code running per day no matter what the language.

Reading between the lines the argument is that *explicit* static typing is just not a good idea, period. Dynamic languages and static languages based on type inferencing are the result of taking this direction to the limit.

I am not convinced static typed delegates vs. static typed classes in and of itself is that significant. Why not simply be able to pass methods around as first class objects without having to declare somewhere that it takes no arguments and returns a boolean? In a large post-modern system there will be at least a half dozen different such explicit declarations for programmers to keep track of.

Jython provides an example of how anonymous classes can be replaced by simple functions rather than pre-declared "delegates"...

In Java...

Button button = new Button(parent, style);
button.addActionListener(new ActionListener() {
    void actionPerformed(ActionEvent e) {
        // Take some action here.
        }});

In Jython, this can be replaced with a keyword parameter and function argument...

    button = Button(parent, style, actionPerformed=self.actionPerformed)
    ...
def actionPerformed(self, event):
    ## Take some action here.

John Robb's New Location

John Robb's new site is up. Great.