True enough about BASIC. However one of the worst design flaws in C is the combination of using = as the assignment operator together with the liberal interpretation of what constitutes an expression. How many lifetimes have cumulatively been wasted because some tired programmer wrote "if (x = y) ..." and the compiler raised no objection? Let's be honest, C is the king of side-effects.
In a sane language, = would not be used as an operator at all, neither for assignment nor equality test. Neither is what the symbol means in a mathematical equation, and allowing it for either is asking for trouble.

Like, the whole plot, for instance? Instead of dragging two droids in and out of firefights, why don't they just email the Death Star plans to the rebel base? Or upload them to a bunch of torrent servers?

If you think that "The Kensington Runestone: Approaching A Research Question Holistically", with its chapters on geology, archaeology, linguistics, and biology is "an exciting book about an epic adventure"... either you've never read the book, or you've already decided what you want to be true. Apparently, you don't even know what conclusion Kehoe comes to. Either way, you've pretty clearly invalidated your qualifications to comment. Look, the stone includes runes that appeared in no dictionary at the time, and this was taken as contemporary proof that it was a bad fake. Those runes were later found to be genuine by further research. How do you explain the presence of genuine runes unknown at the time if its a forgery? And why do you find the fabricated-after-the-fact, unsupported by any evidence fabulation that the stone was transported from Minnesota more plausible than the simplest explanation? Unless you can come up with a credible theory of who transported it, how, when, and for what gain, and how it came to be buried and then found... you've got nothing other than, to borrow a phrase, an epic adventure that you desperately want to be true. For the record, I have no desire, desperate or otherwise, for this to be true or false. I have no historical, ethnic or other attachment to the story. I simply looked at the evidence, and it's obvious which side of the argument is ignoring the evidence it doesn't like...

The Kensington Runestone is almost certainly authentic, for one simple reason. It includes runes that at the time of its discovery were not in any known runic dictionary, which is one major reason it was considered a fake at the time of its discovery by linguistic experts, but decades later were found to be authentic runes. A pretty neat trick for a purported 19th century hoaxer, no? Whoever wrote the Wikipedia entry should probably have a chat with Alice Beck Kehoe of the Univesity of Wisconsin, as she thoroughly deals with all the arguments raised there while providing substantial unanswered evidence for authenticity. I note that her key text on the topic "The Kensington Runestone: Approaching a Research Question Holistically" is not cited in the Wiki entry. Unfortunately, this is what you get when you rely on Wikipedia as a sole source.

"visited", almost certainly; "colonized", more dubiously. It's still up in the air whether the Greenlanders or other Norse actually settled Vinland to the extent of overwintering there, let alone attempting to colonize, or whether they simply established summer camps to hunt and cut timber, which was much needed back in Greenland. Back on topic: what about the anachronistic textual references on the map? Later additions?

Erich Alpha was completely unstable.

Erich Beta was functionally complete, but bugged the hell out of everybody. As of this week, he also shuts down every two hours, which is pretty annoying.

Disclaimer: IBMer here.

You don't need to use the whole set of tools. If you're working in a small team and an Agile process, Rational Team Concert may be the only tool you want. If you're working in a more ceremonial organization you might benefit from other tools in the Rational portfolio, or from integrating whatever external tools you might want. The original internal users of Rational Team Concert were/are themselves small, Agile teams.

I know it goes against a lot of people here's expectations of IBM but really, Jazz is an attempt to do something different and better by a bunch of people with a pretty good track record who were given free rein to build the tools that they themselves would choose to use. If you try out the free edition that runs on Derby and Apache and you still hate it/think its too heavyweight after that, then fine, that's an informed opinion. But I really can't say this strong enough: don't prejudge Jazz by your preconceptions or previous experiences. Fair enough?

Disclaimer: I also work for IBM Rational. I've worked in a lot of other places too and I've been around the block a couple of times.

Maybe it's hard to summarize in a couple of sentences because Jazz really is a number of things. I'll try to describe each of them in one to three sentences. And I'll try not to use marketing buzzwords, although I can't promise not to use URLs.

1. Jazz is the belief that professional software development is a team effort, and the part of that effort that tools in the past have supported least well is communication and collaboration between team members. Tools in the past treated communication more like a ceremony than a conversation. That's just wrong.

The question that Erich and his colleagues set themselves was: what can we do to make it easier to work as a team? So the features that you find across Jazz tools include things like team awareness, status tracking, newsfeeds for things like build completion or test pass/fail, and so on.

2. Jazz is also platform or technology stack that provides common services like storage, query, events, process, collaboration, etc. to tools built on top of it. Middleware for tools, if you like. It relies heavily on Eclipse technologies including OSGi. Rational Team Concert is one example of a tool built on the Jazz platform, there are many more.

3. Jazz also is an integration technical architecture that uses RESTful interfaces between tools, whether those tools are on the Jazz platform or standalone. Links between artifacts are simply URIs. It's designed to be, yes, loosely coupled and web-style. What that means in practice is that you don't have brittle connections where upgrading one tool breaks the integration with another. It also means you don't have to consolidate everything into one repository. The open part of that integration is OSLC, which is where we are developing specs for integration, i.e. metadata definitions in XML and JSON plus service interfaces, in plain sight and publishing them under Creative Commons so that anybody can consume them to integrate with our tools -- or, heck, without our tools if they want to. Anybody can also participate in the spec process -- there's no membership fees or purity test, and the only requirement is a willingness to disclaim patent enforcement against anybody who implements a spec.

Does that help?