Slashdot Mirror

Qt 4 takes threading support to another level, with per-thread event loops, signals--slots connections across threads, and thread-safe implicit data sharing.

Wiki is in Ward's original description:

The simplest online database that could possibly work.

Wiki is a piece of server software that allows users to freely create and edit Web page content using any Web browser. Wiki supports hyperlinks and has a simple text syntax for creating new pages and crosslinks between internal pages on the fly.

Wiki is unusual among group communication mechanisms in that it allows the organization of contributions to be edited in addition to the content itself.

Like many simple concepts, "open editing" has some profound and subtle effects on Wiki usage. Allowing everyday users to create and edit any page in a Web site is exciting in that it encourages democratic use of the Web and promotes content composition by nontechnical users.

Historical Note. The first ever wiki site was created for the Portland Pattern Repository in 1995. That site now hosts tens of thousands of pages.

• http://c2.com/cgi/wiki?WelcomeVisitors
• http://c2.com/cgi/wiki?WikiHistory
• http://c2.com/cgi/wiki?WikiDesignPrinciples

Wiki is in Ward's original description:

The simplest online database that could possibly work.

Wiki is a piece of server software that allows users to freely create and edit Web page content using any Web browser. Wiki supports hyperlinks and has a simple text syntax for creating new pages and crosslinks between internal pages on the fly.

Wiki is unusual among group communication mechanisms in that it allows the organization of contributions to be edited in addition to the content itself.

Like many simple concepts, "open editing" has some profound and subtle effects on Wiki usage. Allowing everyday users to create and edit any page in a Web site is exciting in that it encourages democratic use of the Web and promotes content composition by nontechnical users.

Historical Note. The first ever wiki site was created for the Portland Pattern Repository in 1995. That site now hosts tens of thousands of pages.

• http://c2.com/cgi/wiki?WelcomeVisitors
• http://c2.com/cgi/wiki?WikiHistory
• http://c2.com/cgi/wiki?WikiDesignPrinciples

Wiki is in Ward's original description:

The simplest online database that could possibly work.

Wiki is a piece of server software that allows users to freely create and edit Web page content using any Web browser. Wiki supports hyperlinks and has a simple text syntax for creating new pages and crosslinks between internal pages on the fly.

Wiki is unusual among group communication mechanisms in that it allows the organization of contributions to be edited in addition to the content itself.

Like many simple concepts, "open editing" has some profound and subtle effects on Wiki usage. Allowing everyday users to create and edit any page in a Web site is exciting in that it encourages democratic use of the Web and promotes content composition by nontechnical users.

Historical Note. The first ever wiki site was created for the Portland Pattern Repository in 1995. That site now hosts tens of thousands of pages.

• http://c2.com/cgi/wiki?WelcomeVisitors
• http://c2.com/cgi/wiki?WikiHistory
• http://c2.com/cgi/wiki?WikiDesignPrinciples

On the subject of similar ideas, does anyone remember ThirdVoice? It started out as a way for users to leave comments on websites, but before it died in 2001, I seem to remember it transforming into more of an ad network. Feel free to correct me on this point. At any rate, it was quite close to the smart tags idea.

If the documentation is something such that the other users would be able to help you write (and edit) the documentation further, then use a wiki. I suggest looking the most well-known wiki, and at PHPWiki.

Basically, a wiki will allow them to easily edit and update the documentation without needing to know HTML code, nor needing to have upload/write access to the documentation directory.

If you're the only one who's allowed to edit or make notes on it, then I'd say the best thing to do is start from the top down, and just keep writing as long as you can. The easiest definition of "the top" is usually the starting pount of the app, essentially doing a depth first search. The problem is, if you go too deep, you'll never get the other areas. So, I'd suggest going no more than 2 screens/areas (or 1, if it's really lengthy) deep before moving back up to the top to go on to the next section.

Once you've gotten all of the major/immediate stuff written, go through again and do the next 2 or 3 deeper pages/areas. Keep repeating this cycle until you have everything written.

We can't unionize, because there are simply too many people who can do what we (systems administrators, network administrators, programmers, etc) can do. They might not do it as well but if it takes them twice as long at one fourth the wage that will be good enough to most people.

However getting worried about this is to see the hill and miss the mountain. Outsourcing is just a tiny little worry. What happens as computers continue to get easier to network, and programming continues to move toward open models with users contributing back source for free? We're all gonna be out of work before long. Now admittedly computers don't manage themselves, but that's because very little effort (comparatively) has been spent on systems maintenance automation as compared to everything else. Now that companies are working hard on maximizing uptime and making it a primary priority, I think we're going to see a return to the olden days of receptionist-as-sysop. A consultant will be called in occasionally to fix the hard problems.

Solution? Realize that Specialization is for Insects. You don't have to take things to Longian proportions where you can fix a computer, pilot a spaceship, knock off one or two fine pieces of ass and still make it home in time to cook dinner and play the bagpipes during supper, all while wearing a tux coat and a kilt, but only being good at one thing is a big mistake. In addition all us non-polyglots are going to be in big trouble in the "global economy" which is only getting more global - as many of us have found as we became rapidly unemployed. Actually, it was the dot-bomb that got me, not outsourcing, but I can only assume that outsourcing has made it harder for me to get work.

Lately I've been working on auto body and paint skills, as well as other automotive stuff. A decent body and paint guy can make six figures if he's willing to put in 40-50 hours, is very good at at least one thing and pretty good at a few more things, and lives someplace people have money. It used to be easy to reach/approach six figures in computers, but not any more. If you make that kind of money now it's because you understand the deep voodoo in some complex system, or because you got astronomically lucky.

Of course, cars aren't going to be a reliable way to make money FOREVER. Raise your hand if you thought computers were the sure money... Now lower your hand if you still have a job working with computers that keeps you above the poverty line. Let's compare counts... Now, lower your hand if you still enjoy your job. Count again, and note how many of the hands are still up... Someday the world will swing away from being car-heavy, simply because it will become uneconomical. You might argue that this is true today but as a form of transportation it is hard to beat cars. If you get a relatively efficient one (read: just about anything japanese that isn't an SUV or a full size truck) then you will get very good mileage, the system requires little maintenance, and almost anywhere you go, public transportation is crappy and expensive. It costs $3 for a day pass in Santa Cruz which has a merely mediocre bus system (A very few buses run until 1am, which is not too bad.) $3 will get you about a gallon and a half of gas right now, which around town in my girlfriend's honda will take you probably a good 30 miles. (It might take you almost as far in my 240SX, which has a stock motor, if I wasn't up on the throttle all the time.) But it's only a matter of time before cars swing around again - They, however, will probably continue to hold their place of prominence longer than I am alive.

It's hardly a new problem on the Internet that one can't delete messages from the past...

But what should it be, a whole new library based
on the best from Gnome,
Kde,
Gnustep
Enlightenment Foundation Libraries
and Tao elate
implimentet in Ocaml ??

Ok, I'll ask. What's a "prototype-based object-oriented" language and how does it differ from C++ and Java?

I was wondering the same thing and found the following items:

http://www.dekorte.com/Proto/Chart.html
Prototype-based languages are object oriented langauges where a new object instance is "cloned" from existing live object(a prototype) instead of being constructed by a class. This makes the language simpler by requiring one less data type and solving the infinte regress problem of classes(if you use a class to create an object, what do you use to create a class?). It is also ideal for systems such as GUIs where the pattern of creating one object by copying and modifying another is already handled by the language itself. Check out the site to see a table of similar languages.

http://c2.com/cgi/wiki?PrototypeBasedProgramming
In a class-based language (like Java or Smalltalk), every object is an instance of a class. An object contains its own data (instance variables), but its class holds its behaviour (methods). To make a new object, you ask a class to "instantiate" itself.

In a prototype-based language, an object can contain both data and behaviour. It's a self-contained thing. To make a new object, you just call the "copy" method on an existing object.

The dude who invented this principle phrased it this way (translated from the Latin): "Entities should not be multiplied more than necessary." But what entities are "necessary"? To Ockham, God was a necessary entity, yet you hear Ockham's Razor used to deny the existence of God.

Bottom line: OR is a highly subjective tool that should be applied with great care. And even then, it can mislead you -- the simplest plausible theory can still be wrong, due to evidence you haven't seen. OR is a strategy for coming up with good theories, not a law of nature!

are not inherently fast or slow - implementations are fast or slow, not languages

can be both dynamic and have good performance

can be cross-platform without swallowing POSIX whole

can have multiple inheritance without damaging your brain

can be object-oriented without being object-obsessed

If you like, you can quit as soon as you understand how static scoping and closures work - at least that way you will avoid the primary mistake in pretty much every recent scripting language.

There is a small risk you will become a SmugLispWeenie by doing this, so be forwarned.

Another frequent criticism of AynRand is that she is full of shit; that her arguments lack rigor and are intended to misdirect the reader; and that her novels are a) poor philosophy, b) poor novels, and c) a poor way to express philosophy through a novel. (Contrast with ZenAndTheArtOfMotorcycleMaintenance). Those same people argue that AynRand was not rejected from the academic canon because of elitism, but because she is simply entirely wrong

It is worth noting that Newton's comment was meant in part as a jab at his (short) rival, Robert Hooke.

FOSS software is so great precisely because you are able to build on the work of others, in much the same way that scientific research is (on the whole) open.

No -- Seaside keeps the continuations in memory (just like lisp, ruby, python, perl6 [will], etc...). SISC Scheme and Kali Scheme are the ones that can persist continuations to disk. Or send them over the network to be invoked by a remote client. *bamf* ok, my brain just exploded.

and other root passwords to the US constitution.

This explains why the XP technique of using Code Smells is so effective. "This code smells like crap!"

That brings me to a related point, and that is the irony of some developers' irrational fear of technology. For example, they might "know" C++ but refuse to use Java because they are not familiar (and therefore afraid) of it, even though it might be a better tool for the job. This problem is evident in the area of systems administration as well, for example, the guy who wants to rip out all the working PHP code and replace it with "X" vendor solution (or vice versa) because they're not familiar with the toolkit in question. That sort of thing only does a disservice to the organization because it invariably ends up costing money

The best approach is usually a degree of pragmatism -- try to work within the existing structure, and if you find yourself not understanding what you're looking at, use it as an opportunity to learn something new. Don't be arrogant and assume you're just going to rip everything out and start fresh, and somehow magically avoid the same pitfalls.

" Microsoft didn't just dream this up overnight..."

Like most/all of Microsoft's "innovations", .NET was *purchased*, not created, by Microsoft.

Microsoft inherited what become .NET when they purchased Colusa Software on on March 12, 1996.
At this time C/C++ and VB environments already existed for Colusa's "OmniVM" (which became the .NET CLR?).

To clarify - I do alot of work with C# and find it to be the least unpleasant Microsoft development environment I have experienced.

Score 5, Troll?

And I don't want to work for you. You jump to conclusions based on fragments and obvious hyperbole. You assume "sexism", even for statements that empirically most likely true. You don't understand that programmers need to have quiet time to get to "the flow" and work effectively.

Recommendation: Please, don't hire me.

To be fair, I think you're trying to score a few quick "+1, Funny" moderations, and I understand this. Turnabout's fair play.

(Meta-point: People are human. I defy you to find one person over the age of 20 who has not said at some point "I want to shoot" somebody. As Google research becomes more widespread, it's important for researchers to remember that they aren't necessarily researching how somebody will be in business, they're seeing them in a wide variety of situations, from professional (mailing lists for commercial professional software), through social and maybe semi-professional (Slashdot), through at home and with it "all hanging out" (game mailing lists, personal websites). Again, anybody who expects me to be "professional" for some unsuitably strict definition of "professional" 24/7 had better expect to pay me for that; I'd lay money it's not a standard that they hold themselves to, after all!

By the way, did I mention that I prefer honesty when dealing with people?)

Commercial programmer. OK at first, but eventually I was just doing the same old stuff again and again.

I mean no direct offense, but this may be part of the problem. In general, a programmer should never feel like they are doing the same old stuff over and over again, unless they are being absolutely micromanaged and forced, nearly at gunpoint.

I've been in "IT" for coming up on eight years now, and I've never felt I'm doing the same thing over and over again; for me that's one of the main attractions. This despite the fact that I've now designed at least three organizations sites with dynamic this and interactive that and database the other thing. Each time it's been different.

BoredomIsaSmell. If you're repeating, it's time to automate away the repetition, which is itself generally interesting. As frustrating as my job is sometimes, I'm not sure there's much else I could do; every day is something different.

This holds for "Programmer" (which you claimed you were) and Unix-based tech support. I could never be Windows support; automation exists but is too patchy and incomplete without too much effort.

It is not a crime or necessarily a bad thing, but programming isn't for everyone.

It appears to be Yakov Smirnoff.

If ReST appeals, then a Wiki might also be appropriate. Wiki engines also have the added benefit of tracking versions and allowing anyone to annotate the material. They've been implemented in nearly every language and can be hosted on just about any combination of backends too.

Just something to consider.

Your comment gives the mistaken impression that OSS is somehow destined to always be behind proprietary software, as far as innovation and technical superiority is concerned. Microsoft and SCO love that notion, but unfortunately for them, it's not true. OSS is overtaking proprietary software in many areas, and it's reasonable to expect this trend to continue.

Here are just some of many examples of innovative, open-source software:

Hmmm ... searchguild.com. Could that be the guild?
I agree that it is advisable to click on the direct link or, if clicking on the original link, at least to wear a tin foil hat to prevent falling under the mind control of the new world order.

Anyone else remember The Last One from the eighties? It seems like a 4GL that will free management from pesky programmers is always just around the corner.

Programming is a *creative* skill, at least the way I do it...

Now, there is a great Ask /. : what is the finest troll you've ever seen?
My personal vote was a Lisp apologist who said of c++ "when it has arbitrarily recursive pre-processor macros, I may consider it a real programming language".
But I have to admit, this troll is well above average, and to be respected.

Yes, minimalists love wikis. I'll describe a Wiki for those who haven't seen one: A wiki is a web site where you can modify the pages (usually cgi driven). In its purest form, a wiki is a collection of web page anyone can read or modify, but most wiki software now allows you to restrict access in various ways. Most wikis also version control their pages, so you can undo mistakes made by you, or if it's a world-writable wiki, undo mistakes made by others.

Ward Cunningham wrote the canonical wiki, but there are many others now.

A wiki is somewhat easy to modify (typing your changes into a CGI text box is OK but not the greatest), very easy to search, and pretty easy to link pages together. It's biggest advantage is that you can read and edit it from from anywhere you have a browser. I use a wiki to store notes and links -- I don't keep bookmarks on my browser anymore, so now it doesn't matter which browser I'm using or what computer I'm on. I just set my browser home page to my wiki page that has all my links on it.

If you don't want to run your own, there are wiki sites that will lend you space to do your own thing in (Here's one public wiki, but there are others.

Yes, minimalists love wikis. I'll describe a Wiki for those who haven't seen one: A wiki is a web site where you can modify the pages (usually cgi driven). In its purest form, a wiki is a collection of web page anyone can read or modify, but most wiki software now allows you to restrict access in various ways. Most wikis also version control their pages, so you can undo mistakes made by you, or if it's a world-writable wiki, undo mistakes made by others.

Ward Cunningham wrote the canonical wiki, but there are many others now.

A wiki is somewhat easy to modify (typing your changes into a CGI text box is OK but not the greatest), very easy to search, and pretty easy to link pages together. It's biggest advantage is that you can read and edit it from from anywhere you have a browser. I use a wiki to store notes and links -- I don't keep bookmarks on my browser anymore, so now it doesn't matter which browser I'm using or what computer I'm on. I just set my browser home page to my wiki page that has all my links on it.

If you don't want to run your own, there are wiki sites that will lend you space to do your own thing in (Here's one public wiki, but there are others.

Open source offerings in this area are slim to none, and I've tried everything I can get my hands on. The best I've found is KeyNote, a Windows-only tabbed notebook/hierarchical outliner. I recently converted all my text-file notes over to KeyNote, and found it to be a sweet little package. Highly recommended, although it doesn't really meet any of your other specifications (no hyperlinking, etc., outline-view only).

If you don't mind a web environment, Wikis provide easy editing and hyperlinking, but visualization is not their strong suit. If you like the idea of wikis, but don't want the web, and don't mind paying $12 for closed-source, WikidPad is an excellent, flexible, Windows-only option (and mildly extendable with an embedded Python interpreter). Combines a tree/outline view and Wiki-like syntax & automatic hyperlinking.

If you don't mind closed source, The Literary Machine provides a lot of power in a Windows environment. The basic version was free last I checked, though he's ceased development on it in favor of the Pro version ($20), which is being actively developed and integrates a number of new features (but I haven't tried it yet). It organizes everything based on a non-hierarchical keyword association system, and while it takes some getting used to (and can be downright messy sometimes), it does allow for the discovery of connections between notes that you might not have put together otherwise.

If you don't mind closed source, paying through the nose ($145), and OS X, then there is one app which fits all of your other qualifications: Eastgate's Tinderbox has powerful hyperlinking, programmable agents, RSS and web integration, powerful search, graphical visualization, and plenty more. To tell you the truth, my next computer will probably be a Mac because of this one, though a Windows version is on the horizon (was slated for an early 2004 release, but looks like it's slipped back to Real Soon Now). This has been the sleeper hit of the past couple years--everyone who uses it raves about it, but it's relatively unknown.

Many of the problems with the currently popular software design antipatterns like MVC are that they throw out all of the advantages of true Object Orientation in their zeal to re-invent the 1970's style data processing in OO languages. The NakedObjects folks have an approach that makes it much easier to code in a truely object oriented fashion. This results in more natural, behaviourly complete, objects that are easier to understand, test and refactor. Although this doesn't solve all of the problems that Livschitz mentions, it definitely mitigates the common problems that developers who use OO languages experience and reduces bugs for some of the same reasons that Livschitz cites because it solves the same problems.

Portland Pattern Repository.

Why do people insist on inventing their own scripting languages instead of picking one of the handful of fine existing languages?

Actually, AppleScript's roots harken back to HyperTalk, the inner scripting language of HyperCard. (With minor changes, such as "it" now being called "(the) result").

They wanted to make "system interaction and direction" as easy as making usable stacks was in HyperCard. With AppleScript Studio, it seems like they've finally succeeded.

I wish they'd do something with HyperCard though...

And here's a general OSA link... blah

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

CoSource does this but doesn't have any means for the customer to check whether progress is being made (although they define a third party to judge when the project is completed). And this is where XP comes in: through UserStories, UnitTest s and ContinuousIntegration the customer can always check progress. Plus after each 2-4 week iteration they can terminate the project and only pay for the work done to that point.

XP would not be enforced, can't anyway, but the intention is to offer tools which allow the customer and developers to a) communicate and share ideas, b) allow the customer to see whether progress is being made and c) both sides to check the quality. Tools should not be forced upon projects, however, customers would have the right to define which tools should be used for a project (after all they sponsor the projects). However, to a certain extent, a project should be given time to find it's own tools of choice.

Benefits for customers:

1. Many potential customers can combine forces and allow a product to be dev

What about Palm Python? Okay, limited, no QT, I know.

For my programming needs, the H330 is plenty. There's OnboardC, LispMe, and Dragon Forth. This lets me do the kind of programming I like to do. I recognize that this doesn't fit everyone's needs, but I don't think I'll outgrow my H330 for quite a while. :->

Here's what appears to be an authoritative definition of submarine patent..

A Submarine Patent is a patent which an "inventor" files on a device or technology that doesn't exist yet, or which has not yet been successfully implemented. Using various procedural mechanisms, the filer intentionally delays issue of the patent, sometimes for years, until a practical implementation of the device/technology appears on the market. At that time, the filer allows the patent to "come to the surface" and demands royalties from the party who did the real work.

http://c2.com/cgi/wiki?SubmarinePatent

Maybe it's time to break from the lemming-like rush to format absolutely everything in XML.

If you want a concise, readily-parsed alternative, consider UBF - don't let the title of the paper throw you; it's really about a lean alternative to XML.

Or just enjoy some alternative viewpoints on the subject at the Portland Pattern Repository's XML Sucks page.

What other language can control a spaceship millions of miles away than LOGO?

Very well said, albeit depressing as hell. I'm not American, but this is rampant in the EU too. Politicos, businesses and media, all busy creating artificial focal points of power and authority. Whether it's presidencies or punch-line agendas, dumbed-down 'news' or brands as identity/lifestyle.

Reminds me of the Facade pattern ("...can be used to simplify a number of complicated object interactions into a single interface."). We, the public, only get to play with facades; the important stuff abstracted away, protected and out of reach.

It makes perfect sense, that searching for any single or few points of control/power (a president, a product/service/brand, a standard 'journalistic analysis', etc.) is naive and simplifying. As is easy to see, changing a few pieces on the chessboard doesn't change the game; we'/they're still caught playing chess...

Making noise and protesting probably is close to all we can do. Though even that can get dangerous quickly, especially in a society with fewer rights to privacy and with eroded individual and 'cultural' freedoms. Something we discussed here, about Paul Graham's fine essay What You Can't Say

It increasingly looks like "the system" fights hard to file down the teeth on the parts of democracy that can bite back and hurt "the system" itself..

Jesus, this is both frightening and depressing. And it's back to work in less than 8 hours. Unh.