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?