It is their job to represent the will of the people (ALL the people, not just the wealthy contributors) that they are supposed to be governing.
What about cases where a politician is elected (even by more than 50% of the voters) but his constituency disagrees with him on a particular issue (say, 75% against him) -- should he go with his declared platform (which was bought as a whole) or the will of the people? (I'm not saying that's the case here at all. I'm wondering what should define "the will of all the people" in the mind of the idea politician.)
You're not likely to convince me to use a full XML database, no.
However, we should consider the viability of storing what you and others describe as unstructured documents in blobs with server-side operations available to you. Just because you're going to have some XML values (that's what they are) in your database doesn't mean the whole thing needs to be XML, nor does it mean you should have to do all operations client-side because you're using a relational database. What it does mean is that if you're determined to have XML values, you should have XML functions that match them. Nothing about the relational model prevents you from having this sort of complexity available to you, most vendors have just been slow to provide tools. A lot more could (and should) be done in the area of functional indexing so you don't have to "take things apart" in order to index them, too. I shouldn't have to create a separate "words_used" table to do full-text indexing on an attribute. To be fair, the relational model also doesn't say you have to break things down into small fields; I think people often get confused about this. RDBMSs usually only come with basic datatypes defined (integer, text, date/time, etc.) but it's perfectly acceptable to have field types of "list of integer" or "set of text" or "mapping of text to pair of integer and string" (yes, I generally code in C++, so STL structures come to mind). Having a field type of "XML stuff" is also acceptable.
The key element here is, however, the claim that you don't control the format of the data you're receiving. Yes, you can use XML-only tools on your documents because they're all known to be XML documents. But if you truly don't control the input, shouldn't you also have to deal with PDFs, TXTs, TIFFs, etc.? The point is that you do control your input, you have a baseline spec to deal with. In fact, you might have more: you might require all XML documents to have, more or less, the same structure. Do you? If you do, then that's an extra assumption you can use to your advantage. Every time you make such an assumption, you're working toward normalizing your data.
Abstractly, it would be just as appropriate to require all documents (particularly in the case of repair manuals where there are obvious patterns) to be in a very specific format, relational even. Why not? You've got them all using XML, and that's not necessarily the easiest thing to deal with -- in fact its "model" (if you can call it that) is far from simple, with a lot of gotchas (difference between putting data in a tag's attribute vs. putting it between tags.) You can't query what you don't have; just because manuals are in XML format doesn't mean you can ask "how long will this procedure take" and have it calculate the sum(step.time_required) for you, unless you actually have the data normalized. And if you've got it normalized, then the argument for XML ("it's not normalized and can't be") falls apart. The only reason you can ask how often certain part numbers are mentioned together in the same procedure is, specifically, that you know how and where to find part numbers (not just numbers of any sort) in the repair procedure. To do so, you've got to have assumptions about your document. Assumptions lead to normalization in a rather straightforward manner.
But to be clear to those who might think us confused: XML is physical (file format), relational is logical (data model). Speed is physical, features are logical. I've seen fast SQL and I've seen dog-slow SQL, just as I've seen fast and slow sorting algorithms, memory-management algorithms, etc. Speed, in general, is easy to improve. What's not easy to improve is a feature-set when you've locked yourself in. And that's why the relational model is important: it's logically, mathematically proven. Its operations are well-defined.
I'm not sure what we'd try to convince each other of at this point. Pretty much just talking past each other. As you say, convincing seems unlikely.
If you routinely get questions like "how often is part 1976 mentioned in the same repair procedure as part 2001?" or "which of our 150,000 documents have chapters containing five or more subsections any of which does not yet have a summary?" then the XML approach becomes more interesting.
select count(distinct A_repair_proc_parts.repair_proc_fk) from repair_proc_parts A_repair_proc_parts inner join repair_proc_parts B_repair_proc_parts on A_repair_proc_parts.part_number = '1976' and B_repair_proc_pairs.part_number = '2001' and A_repair_proc_parts.repair_proc_fk = B_repair_proc_parts.repair_proc_fk;
create view bob0 as select chapter_subsections.id, chapter_subsections.document_chapter_fk, count(subsection_summaries.id) summary_count from chapter_subsections left join subsection_summaries on subsection_summaries.chapter_subsection_fk = chapter_subsections.id group by chapter_subsections.id, chapter_subsections.document_chapter_fk;
create view bob1 as select document_chapters.id, document_chapters.document_fk, min(bob0.summary_count) min_subsec_summary_count, count(chapter_subsections.id) subsec_count from document_chapters left join bob0 on bob0.document_chapter_fk = document_chapters.id left join chapter_subsections on chapter_subsections.document_chapter_fk = document_chapters.id group by document_chapters.id, document_chapters.document_fk;
select distinct documents.id from documents inner join bob1 on bob1.document_fk = documents.id and bob1.min_subsec_summary_count = 0 and bob1.subsec_count > 4
I just woke up, so I expect some bugs, particularly as I didn't test any of it. But I still fail to see how this was supposed to be hard, and how XQuery really makes it any better. Sure, I could code the above as a C or perl or whatever program running through data (PLAN NATURAL), but why?
The first one would be easier if RDBMSs came with a DIVIDE BY clause as suggested by Date/Darwen/Pascal. It's perfectly appropriate for that sort of query, and quite relational. The second is just a nasty request, and anyone who does SQL much is probably accustomed to that. Users come up with the darndest requests sometimes. Also note that I assumed certain relation layouts, perhaps I assumed incorrectly. (Documents, chapters, subsections, and summaries would, most likely, just all be in one table. At that point, see my table names as views which select from some single table, DOCUMENT_CHUNKS where, say, DOCUMENT_CHUNKS.TYPE = various values for each view.)
Non-normalized data is the result of people not caring enough / being lazy / not getting the information they should have to do their job. It's not an incurable disease.
As I happen to have been reading up on them recently... (we -did- code in C++ without Boost, and have done just fine so far, but felt it might be handy for a few odd situations)
auto_ptr is pretty much equivalent to Boost's scoped_ptr: it just makes sure that when the -1- pointer to your object goes out of scope, the object is deleted. this is good for securing objects around try/catch blocks or early returns, where you would have to manually plan for each possible exit and code your deletes appropriately. these are not safe in STL containers, which copy values around. you'll wind up having a pointer go out of scope and delete your object.
shared_ptr is reference-counted, though it doesn't handle circular refs for you. weak_ptr is used for this, though the examples I found weren't terribly clear on the topic. unlike java's garbage collection, you have a pretty clear idea of when an object will be destroyed (when the last shared_ptr to it is destroyed). these are safe in STL containers.
intrusive_ptr lets you do reference-counting yourself in the objects the pointers will reference. that has the additional benefit of letting your objects know how many references to them there are, which they wouldn't know if you were using shared_ptr. but you have to code a little more yourself.
regardless, you have to be careful. these aren't language-enforced, so unlike java and other GC'ed languages, you can easily screw over your garbage collection by using raw pointers instead of smart pointers. you'll have to enforce a level of discipline. typedefs recommended? maybe even a separate class that hides the smart pointer entirely and is passed around by copy?
working from PHP with Firebird seems to be not too native
Really? I've found the ibase_* functions rather clean, though php.net's examples fail to clearly indicate how to use transactions, even though it's quite easy (and a really good idea.) I wonder if that's just part of the "get up and going" approach, or a hold-over from other *cough*MySQL*cough* RDBMSs that didn't have/encourage transactions.
While we use IBX for our Win32 apps, we don't use any of the visual components, and we could just as easily do with IBObjects, or even a few wrappers around the C API. We use IBX about as much as I use the ibase_* functions in PHP, with wrappers to STL structures. (Note: IBX isn't guaranteed to continue working with Firebird, as Borland does its own thing with Interbase. We're screwing ourselves over by using it.)
Do you convert the database layout to a data-warehouse/star topology for use with MySQL? I could see how a simpler table layout, particularly for mostly read-only operations, would make MySQL more appealing. (Firebird has a read-only mode in which transactions are ignored and things speed up, but we've never used it. All our reporting is done against the live database, up to the last committed transaction. Managers won't have it any other way.)
I thought I heard something about PG's "vacuum" being fixed/replaced in the near future, so the 24x7 thing won't be an issue anymore?
I was at Barnes & Noble tonight, waiting to go pick someone up at the airport. Looking through the tech-book section, apart from noticing a lack of theory books, I noticed that MySQL has done well for itself in the publishing world. SQL books most often refer to MySQL for examples, PHP books (and other "learn this language so you can incorrectly apply what you halfway learn to any problem you encounter" books) generally include a large section devoted to database stuff, seemingly always involving MySQL... There were more MySQL books than Oracle books, more Oracle books than MS-SQL books, more of those than of PostgreSQL books, and no Firebird, MaxDB, Ingres, DB2, Cloudscape, HSQL, etc. books that I recall.
If most all programming were taught in Basic, don't you think people would wind up coding apps in Basic, regardless of its actual worthiness? (Today, it's Java, not Basic. But now I've called upon myself the wrath of the Java coders.)
I personally use Firebird at work and at home. Installation is a snap, particularly from binaries. Unpack, run installer, go. Works under *nix and windows, and has an embedded version appropriate for standalone apps. Its creator is the father of generational record-keeping (which some RDBMSs like MS-SQL have only recently gotten around to), and it's like an "easier to use under windows" cousin to PostgreSQL, feature-wise.
Other than good marketing (including a lot of word-of-mouth rumors) in favor of MySQL, I can't explain its success. When you have to help someone implement a query as a correlated sub-query because their RDBMS of choice (MySQL) doesn't do certain joins properly, or doesn't do them quickly (yes, even with indexing -- the optimizer is just stupid),... you start to wonder why they don't use an RDBMS where they can express exactly what they mean, directly, and have it be fast. And MySQL's popularity has lead to a lot of people learning some very bad habits (particularly about doing a lot of client-side work, like joins or aggregates, or using sub-queries where joins should work)... but people love it! (I think this is related to the stockholm syndrome, in a way; I also see it with data-entry clerks who are convinced that their crappy, buggy, expensive, old, vendor-supplied software is better than anything anyone will ever build, ever. If you're an in-house programmer, you're not a real programmer, either. Masochists.)
If that message happens to trigger a large financial transaction, that would be a bad thing.
Isn't this why we should be concerned with transactions, two-phase-commit, transaction managers, and asynchronous commit replies? Submit request, continue processing, and if you don't hear back about your commit for a while, do something about it? I dunno. If you want reliability, you need some way to audit your process to make sure things are actually happening as reported. Admittedly two-phase-commit has issues (ask any DBA who has to manually resync databases where limbo transactions have stacked up) but... still.
There was an accepted standard of interoperating across the C calling convention. As long as various languages supported the standard calling convention (there's nothing special about the C one, almost any would do), libraries and code could be re-used (and use each other) without worrying about using whatever language someone else decided on. The bottom line is this: if I want to code in C and you want to code in Java and someone else wanted to use PHP and yet another person wanted to use Fortran or *shudder* Cobol, we shouldn't have to re-implement the libraries every time, we shouldn't have terribly convoluted mapping functionality to gain access to libraries (the JNI isn't exactly pretty) and we really shouldn't have to worry about it much at all.
The way we do things, our language wars are much more than just language wars: when someone argues for Java, they're also arguing (sometimes without realizing it) for all the already implemented Java libraries vs. libraries available by default in other languages. When you advocate Perl, you're also advocating CPAN. With PHP, you're advocating PEAR. Some of them internally re-use other libraries (particularly ones written in C) but that doesn't guarantee anything. Because of library incompatibilities, when you select a language, you have to do so based on the available code, not just on the language itself.
When you switch languages because something's easier or quicker or more obvious or readable or whatever in a language X, you shouldn't have to hunt down a whole new set of libraries that may or may not interface with equivalent libraries in the language you were just using, in turn meaning your apps can't (at least not easily) interoperate. So while I try to tell people there's nothing special about coding in C++, that it's not "better" than other languages, just easier for me to use and therefore my preferred tool, the truth is that if I switch languages for a particular chunk of a project, it's an enormous hassle to make things work together, and I'm not willing to deal with that.
It's vendor lock-in, and we happily go along with it. Sometimes it's just because language designers don't think of this as something they need to support, but in the case of companies like Sun or Microsoft, I think there's more to it.
It's entirely possible to write maintainable code in a language other than Java, programmers have been doing it for years. From my experience, it depends more on the programmer than the language -- whether or not you're able to think ahead, care about doing so, and do so usefully. And then document what you do, what you didn't do, and why. That's not much to ask, is it? Bugs happen in any language. Why not claim that laws make crimes (or even accidents) not happen?
For the OO definition: inheritance is vague. It means you keep at least the interface from one other class; it doesn't say whether or not you can get multiple interfaces from other classes, and it doesn't say whether or not you can get implementations of those interfaces from other classes (and if so, how many -- just 1, or several, or always all?).
The fact that you can do this means you can have dangling pointers, access violations, etc. like any other language that supports pointers at all. I'm just pointing out that there are ways of abusing the language. If you use pointers in C correctly, you won't have any problems either. If you use any language correctly, you'll not have any problems. If you use any language even remotely unsafe incorrectly, you can have problems. Most languages are at least slightly unsafe in one way or another; some allow you to turn off error checking, range checking, type checking, etc., sometimes even dynamically, around a single chunk of code, etc.
Why do people think of Pascal as inherently safe? If you want to mess with pointers, it's really rather easy. Stick 'em in a variant (union) record, do your arithmetic against another named integer, and there you go. I mean really...
"Object-oriented programming" is ill-defined. It encompasses a lot of languages that go about it in entirely different ways. To me, the most it can mean is "calling functions with an assumed this pointer." What does OO mean to you? Virtuals? What makes it "real"?
There are benefits to C beyond speed and direct access to memory, hardware, etc. People seem to forget that for us to make software "work together", calling conventions across libraries need to be compatible. Which is why we picked C calling conventions. It's not necessarily the most expressive if you're into fancy things, but it is flexible enough for most everything. My main problem with Java isn't the language -- it's the libraries. Lots of them, packaged in their own special way, not really designed for use by any language.
Languages, most of the time, aren't the issue. We haven't gained all that many 'new' features with new languages, at least not anything we can't easily live without. Access to symbols is an issue, however, and a really important one from the point of view of integration, code re-use, and even making sure you're using trusted/proven code.
Regardless of buffer overflows, you can still write infinite loops, incorrect logic, etc. in just about any language. These language wars are about markets -- they're about money.
No. Your links point to the results of a 1000-phone-call survey of all ages (see age distribution at bottom of results). The results are still interesting (and made me very sad,) but they are not the same as those the grandparent was asking about.
Databases (typically relational) aren't just fast because of indices; they can also assume more about the structure of the data. A table (relation) is a set of tuples, each one with the same attributes, each one with a single value (however complex it might happen to be, in spite of what OODBMS people think.) When you've got that, you only need to store the meta-structure of the relation once, in the relation header. Then you can assume all sorts of stuff about what's to follow, and you can optimize the hell out of the data (CSV is so much more efficient than XML for transmitting relational data, it's amazing. And it's not even good.)
On the other hand, when you've got a document in which structure fluctuates wildly from item to item, and you have to look at the item to know what it might be (let alone whether or not it's what you're looking for, what you can do with it, etc.)... things take a little longer. XML just doesn't have shortcuts for "and now some relational data" that can speed that up.
Then again, when you're sending data, it seems redundant to send indices -- that's the sort of thing each receiving party should recreate as desired. But nobody said XML was about efficiency in reading/writing/searching/manipulating. It was about a standard, do-almost-anything, here's-a-prewritten-library-for-you, read-file-until-you-grok-it format. Efficiency's not in the list.
My girlfriend is often called out to people's homes to transfer their data to a new Dell (yeah, it's always a Dell). At some point a few months ago, she was asked to do this for a manager at a big tech company, who works from home. She didn't have the CD's with her for stuff like MS Project, so it couldn't be installed on the new computer. The files themselves, however, were copied. Rather than blaming herself for not having the CD's, or going out and buying a new one, she just complains that her files weren't copied. Application and Content are separate, but without the Application, people fail to understand that their Content has been copied. They don't understand why it's such a pain to try to copy Applications, obviously. Admittedly, it's less of a pain on, say, MasOS... but Windows? Some software companies seem to delight in designing a maze of environment variables, registry keys, paths, dll's in random directories, etc. (But yes, Application == Content, it's all just bytes. Some are just easier to copy than others.)
Does a C API count? The Firebird project is open-source, has a.dll version of the server for embedding, and is written in C/C++ (they're converting everything over to C++ classes and exceptions.) It has a C API, for which you can find minimalist C++ wrappers. Firebird's footprint is really quite small, it's generally fast, it has good transaction semantics, good sql support, stored procedures, triggers, generators,... it's sort of considered a cousin to PostgreSQL (they've concentrated on slightly different feature sets.)
Most people are too lazy to enter good metadata in webpages, even assuming a good, standard way of doing so. However I see some future in sites like GlobalSpec where your search is narrowed down until you know exactly what type of product you're looking for, and then extra metadata for that class of products is exposed in the search (usually in the form of sets of checkboxes and ranges of metric-aware values) -- allowing you to search by thread size on bolts, but not on other equipment where it's not relevant. I think some sort of community-driven version of this could be nice; let users create new types of attributes (or whole modules) for new types of 'items' and search using better metadata. Eh. It's an idea.
France has a system similar to this. At the end of 9th grade, you take a test (Brevet) to determine whether or not you're really fit for university studies. If you are, you go to a standard high school, and pick a specialty (language/arts, math, physics, biology, economics, etc.). You're expected to continue on to university studies in whatever specialty you've chosen. If you don't pass the test, you have the option of moving on to various tech-ish schools, again specializing into whatever field you seem interested in. You're not really expected to do university studies as a result, but you should be able to find a job. There's less stigma than with tech schools in the states, but still some. I had friends who went the alternate route, and though one got hired and trained in accounting right out of it, he still wasn't happy he hadn't made it into the "normal" high school. "Equal but separate" rarely works. Maybe if it were entirely up to the student (not based on scores) but even then...
The fact that I'm not married but live with my girlfriend "hurts" my mother too, but that's no reason to throw me in a mental hospital or use laws to change my behavior. If we had to consider everyone who would be hurt or offended by our uses of personal liberty, we'd never get anywhere (there's always someone.) Your first argument was better than your second.
As to mental illness, I still find it offensive that we just (blanket-statement) declare those who attempt suicide to be mentally ill and no longer responsible for their actions, needing to be placed under someone's guardianship until they recover. We should be very careful with this sort of thinking. If we do this withouth thinking it through and carefully justifying our decisions, we're not very far away from the realm of "gays are mentally ill" or "rebels are mentally ill" or "communists are mentally ill". (It's not a slippery slope; but it's equally unjustified.)
"How could anyone in their right mind possibly do something like that?" is what you mean by "normal people [...] never do." It also means that someone who is terminally ill (say, with cancer or AIDS) is no longer allowed to make the decision to die slightly early to ease the pain. Obviously, they're mentally ill to wish such a thing, right? Maybe we should just drug them up some more until they can't tell what's going on; at least vegetables don't try to commit suicide.
The court would argue for the victim that no such oral contract existed, and require written, signed, notaried proof on the matter. Considering the apparent conflict of interest, the jury would likely not believe the defendant's claim about such an oral contract.
The point here is that children don't have the legal ability to make decisions like that, and parents can't do that for them either, generally. For example, a child can't generally consent to sex until fairly old, and parents certainly can't consent for them (or else all those cases of parents sexually abusing their children would suddenly get nixed.) Sure, we can change that, but it'll require rethinking all of our consent laws (and principles.) An emancipated child could make these decisions, yes. But the process of emancipation is rather odd. (Automatic vs. not; not letting children do to themselves that which is unsafe, etc.) How do we let a child make this decision for himself yet also give parents the right to tell their children 'no' to simple things like stabbing a pencil in their arm? Thoughts on the matter?
Our nation's economics are founded on the idea that we don't know what's best for us, and that relying on individually greedy, selfish people will get us the 'best' results by hit-and-miss. Since when do we enforce what's 'best' for us by law? (Okay, we try to, but since when is it also a good idea?)
As you pointed out in your other post, you need to show harm done by pornography. But not just to self. It's not a crime to be depressed or self-hating, for example. We've even upheld your right to commit suicide, and hurting yourself on purpose (cutting) is at most going to land you in a mental hospital while someone tries to figure out if you're sane enough to have rights or not. Does pornography hurt others, then?
How does pornography harm others? The only way it could is through the actions of individuals. And the only way we could blame porn itself is if in at least the extreme majority of cases, the individuals involved had lost all self-control and were no longer responsible for their actions. But even then, consider drugs. Just because being drunk makes you unable to maintain self-control doesn't mean that your actions are now alcohol's fault in general. It means it was your fault for abusing of the stuff in the first place, knowing what it would do to you. Porn's the same way. If you're not going to be able to maintain self-control if you're around porn, then it is your duty to avoid it; if you do not, you'll still be liable for whatever you wind up doing.
And hurting society? Laws shouldn't attempt to maintain the society however it was 'before'. Laws don't get re-approved at each generation, at each person being born. We are what we are. Over the course of human history, have our societies changed for the worse so much we have a clear example of it? The world's always going to hell in a handbasket, yet we never really seem to get any worse. If you read, say, the Meditations of Marcus Aurelius, you'll see his society was pretty much exactly like ours, no worse, no better. Do we need our laws to try to prevent natural, small shifts in every-day morality? It won't do any good. A few generations later, someone will get up the courage to change the laws, and your efforts will be for naught. You can make change more painful, but you can't prevent it. So should we try to mold our society, our culture, through law? No. We can, at any point in time, attempt to punish our citizens for harming each other, and that's about it.
Murdering someone (that is, killing them without their consent) deprives them of their ability to bring suit against you in court. The victim cannot bring charges, so the State (the People) feels it is dutiful to do that in place of the victim. The same should be true of any case where the victim cannot bring suit -- complete and utter lobotomy, permanent coma, etc.
Killing someone (including yourself) who has asked you to shouldn't be a crime, so long as that person has ability to give consent. A child's request for euthanasia should be ignored, for example. And there are some things parents can't consent to in the name of their children -- like dying.
However, even if our basis for creating laws is moral, law remains law -- by staying here past the age of majority, you consent to the laws of the land, regardless of their origin or nature. You agree to be punished for certain actions, and murder is one of them. Because law does not require that it be justified, it often is not. When states are particularly afraid they'll be accused of crossing some sort of church/state boundary, they'll just have a referendum instead -- let the people make the decision, so you don't need any justification whatsoever. Is it moral? Maybe. But the law doesn't encode that part.
Stargate: Atlantis should have been called Stargate: Voyager. I mean really; you've got a woman in charge of a group of people stranded on the far side of nowhere with no way back in a hostile environment (with the main enemy being some sort of slimy alien intent on human doom,) they pick up some locals to help guide them within the first episode, becoming grand pals... and they're trying to be as funny as SG1 and are failing miserably. No, see, that might have worked for Star Trek, but I have a feeling SciFi's going to realize that it's not working for Stargate. And then we'll really be in trouble. (Just so long as they don't have a new prequel show too...)
It's really too bad, in both cases. Enterprise and Atlantis both have interesting back stories to explore, giving our imaginations a bit more fuel for a while to come. Enterprise was going to give us the Federation -- with only one season to do it in, and having wasted a whole season talking about the war on terrorism (which they then did again, from the other point of view, with the vulcan episodes recently), I'm not seeing that getting done in time. Enterprise will be remembered as the ship with a couple of missions that never got around to doing its job of exploration, peace, etc. Atlantis hasn't gone far enough yet that an abrupt end would hurt the series as a whole, but it wouldn't take long -- just a few good stories and that's that.
P2P networks have had fairly good copies of Enterprise, at least, available within a week after airing. For those who could and would have watched it had it not been so badly placed (or had they not been out of town, or their equipment on the fritz,) that's a solution that doesn't involve DVR's. But it doesn't help the TV ratings.
The robot might have been "excessive", but it's useful in a proof-of-concept sort of way. Video is a 2d projection only; for something as complex as dance (can be), having an actual 3d recording of the moves is superior to a 2d recording. This could have been done with holograms, but recording the actual position of limbs is probably still superior to a visual recording of their position. This is a case where video is nice, but there are better ways of recording the underlying information. The robot is just a method of viewing this precise, not really ambiguous at all, data.
Not to flame, but the insinuation of my post was that most of the linux gui toolkits are mimicking windows -- and therefore failing to make true innovations, just improvements (which are great too, by the way.) If someone can point me to existing projects that (want to) do this, that'd be great. But as pointed out elsewhere -- like e17, who's going to change their apps over now to use some sort of semantic gui abstraction layer? The apps are written, we're locked in. We still keep pure X compatibility because of apps from decades ago that haven't switched to anything newer.
While we're at it -- isn't this all sugar anyway? Do we get more semantically-interesting constructs? I'm in the middle of building a new set of components for our existing application (it'll be a pain in the ass to go and fix all 500 screens, oh well) to be more semantically-aware. I don't want a "combo box" or an "edit box" -- I want a "select one item from this list of items / tree of items / graph of items" box, or a "decimal, positive number with a metric unit attached to it with automatic unit conversion" or any number of other data-aware components, not method-of-input-aware components. I don't think I get that with this set of updates, just "prettier" components. Anyone who cares enough, please feel free to correct me. But from my perspective, we should be working on semantic controls -- if the user prefers a set of radio buttons for small lists of items, so be it, so long as the end effect (selecing exactly one and returning the selection) stays the same. Got table data, or even some sort of multi-table in-memory database the user's looking at? Let them decide how they want to look at it, and give me, the programmer, the ability to do that for more than just my own app. It seems like a crime to still not have that by now... Unix app, Mac app, DOS app, Windows app, it's all the same from a semantic point of view. There's data the user wants to see, and there's data we need from the user to do things -- who cares what it looks like on the programming side? *sigh* At least we've got database servers, filesystems, query/programming languages, and all that figured out. Wait. Nevermind. *sigh* Back to coding those components...
Slashdot Mirror
It is their job to represent the will of the people (ALL the people, not just the wealthy contributors) that they are supposed to be governing.
What about cases where a politician is elected (even by more than 50% of the voters) but his constituency disagrees with him on a particular issue (say, 75% against him) -- should he go with his declared platform (which was bought as a whole) or the will of the people? (I'm not saying that's the case here at all. I'm wondering what should define "the will of all the people" in the mind of the idea politician.)
You're not likely to convince me to use a full XML database, no.
However, we should consider the viability of storing what you and others describe as unstructured documents in blobs with server-side operations available to you. Just because you're going to have some XML values (that's what they are) in your database doesn't mean the whole thing needs to be XML, nor does it mean you should have to do all operations client-side because you're using a relational database. What it does mean is that if you're determined to have XML values, you should have XML functions that match them. Nothing about the relational model prevents you from having this sort of complexity available to you, most vendors have just been slow to provide tools. A lot more could (and should) be done in the area of functional indexing so you don't have to "take things apart" in order to index them, too. I shouldn't have to create a separate "words_used" table to do full-text indexing on an attribute. To be fair, the relational model also doesn't say you have to break things down into small fields; I think people often get confused about this. RDBMSs usually only come with basic datatypes defined (integer, text, date/time, etc.) but it's perfectly acceptable to have field types of "list of integer" or "set of text" or "mapping of text to pair of integer and string" (yes, I generally code in C++, so STL structures come to mind). Having a field type of "XML stuff" is also acceptable.
The key element here is, however, the claim that you don't control the format of the data you're receiving. Yes, you can use XML-only tools on your documents because they're all known to be XML documents. But if you truly don't control the input, shouldn't you also have to deal with PDFs, TXTs, TIFFs, etc.? The point is that you do control your input, you have a baseline spec to deal with. In fact, you might have more: you might require all XML documents to have, more or less, the same structure. Do you? If you do, then that's an extra assumption you can use to your advantage. Every time you make such an assumption, you're working toward normalizing your data.
Abstractly, it would be just as appropriate to require all documents (particularly in the case of repair manuals where there are obvious patterns) to be in a very specific format, relational even. Why not? You've got them all using XML, and that's not necessarily the easiest thing to deal with -- in fact its "model" (if you can call it that) is far from simple, with a lot of gotchas (difference between putting data in a tag's attribute vs. putting it between tags.) You can't query what you don't have; just because manuals are in XML format doesn't mean you can ask "how long will this procedure take" and have it calculate the sum(step.time_required) for you, unless you actually have the data normalized. And if you've got it normalized, then the argument for XML ("it's not normalized and can't be") falls apart. The only reason you can ask how often certain part numbers are mentioned together in the same procedure is, specifically, that you know how and where to find part numbers (not just numbers of any sort) in the repair procedure. To do so, you've got to have assumptions about your document. Assumptions lead to normalization in a rather straightforward manner.
But to be clear to those who might think us confused: XML is physical (file format), relational is logical (data model). Speed is physical, features are logical. I've seen fast SQL and I've seen dog-slow SQL, just as I've seen fast and slow sorting algorithms, memory-management algorithms, etc. Speed, in general, is easy to improve. What's not easy to improve is a feature-set when you've locked yourself in. And that's why the relational model is important: it's logically, mathematically proven. Its operations are well-defined.
I'm not sure what we'd try to convince each other of at this point. Pretty much just talking past each other. As you say, convincing seems unlikely.
If you routinely get questions like "how often is part 1976 mentioned in the same repair procedure as part 2001?" or "which of our 150,000 documents have chapters containing five or more subsections any of which does not yet have a summary?" then the XML approach becomes more interesting.
select count(distinct A_repair_proc_parts.repair_proc_fk) from repair_proc_parts A_repair_proc_parts inner join repair_proc_parts B_repair_proc_parts on A_repair_proc_parts.part_number = '1976' and B_repair_proc_pairs.part_number = '2001' and A_repair_proc_parts.repair_proc_fk = B_repair_proc_parts.repair_proc_fk;
create view bob0 as
select chapter_subsections.id, chapter_subsections.document_chapter_fk, count(subsection_summaries.id) summary_count from chapter_subsections left join subsection_summaries on subsection_summaries.chapter_subsection_fk = chapter_subsections.id group by chapter_subsections.id, chapter_subsections.document_chapter_fk;
create view bob1 as
select document_chapters.id, document_chapters.document_fk, min(bob0.summary_count) min_subsec_summary_count, count(chapter_subsections.id) subsec_count from document_chapters left join bob0 on bob0.document_chapter_fk = document_chapters.id left join chapter_subsections on chapter_subsections.document_chapter_fk = document_chapters.id group by document_chapters.id, document_chapters.document_fk;
select distinct documents.id from documents inner join bob1 on bob1.document_fk = documents.id and bob1.min_subsec_summary_count = 0 and bob1.subsec_count > 4
I just woke up, so I expect some bugs, particularly as I didn't test any of it. But I still fail to see how this was supposed to be hard, and how XQuery really makes it any better. Sure, I could code the above as a C or perl or whatever program running through data (PLAN NATURAL), but why?
The first one would be easier if RDBMSs came with a DIVIDE BY clause as suggested by Date/Darwen/Pascal. It's perfectly appropriate for that sort of query, and quite relational. The second is just a nasty request, and anyone who does SQL much is probably accustomed to that. Users come up with the darndest requests sometimes. Also note that I assumed certain relation layouts, perhaps I assumed incorrectly. (Documents, chapters, subsections, and summaries would, most likely, just all be in one table. At that point, see my table names as views which select from some single table, DOCUMENT_CHUNKS where, say, DOCUMENT_CHUNKS.TYPE = various values for each view.)
Non-normalized data is the result of people not caring enough / being lazy / not getting the information they should have to do their job. It's not an incurable disease.
As I happen to have been reading up on them recently ... (we -did- code in C++ without Boost, and have done just fine so far, but felt it might be handy for a few odd situations)
auto_ptr is pretty much equivalent to Boost's scoped_ptr: it just makes sure that when the -1- pointer to your object goes out of scope, the object is deleted. this is good for securing objects around try/catch blocks or early returns, where you would have to manually plan for each possible exit and code your deletes appropriately. these are not safe in STL containers, which copy values around. you'll wind up having a pointer go out of scope and delete your object.
shared_ptr is reference-counted, though it doesn't handle circular refs for you. weak_ptr is used for this, though the examples I found weren't terribly clear on the topic. unlike java's garbage collection, you have a pretty clear idea of when an object will be destroyed (when the last shared_ptr to it is destroyed). these are safe in STL containers.
intrusive_ptr lets you do reference-counting yourself in the objects the pointers will reference. that has the additional benefit of letting your objects know how many references to them there are, which they wouldn't know if you were using shared_ptr. but you have to code a little more yourself.
regardless, you have to be careful. these aren't language-enforced, so unlike java and other GC'ed languages, you can easily screw over your garbage collection by using raw pointers instead of smart pointers. you'll have to enforce a level of discipline. typedefs recommended? maybe even a separate class that hides the smart pointer entirely and is passed around by copy?
working from PHP with Firebird seems to be not too native
Really? I've found the ibase_* functions rather clean, though php.net's examples fail to clearly indicate how to use transactions, even though it's quite easy (and a really good idea.) I wonder if that's just part of the "get up and going" approach, or a hold-over from other *cough*MySQL*cough* RDBMSs that didn't have/encourage transactions.
While we use IBX for our Win32 apps, we don't use any of the visual components, and we could just as easily do with IBObjects, or even a few wrappers around the C API. We use IBX about as much as I use the ibase_* functions in PHP, with wrappers to STL structures. (Note: IBX isn't guaranteed to continue working with Firebird, as Borland does its own thing with Interbase. We're screwing ourselves over by using it.)
Do you convert the database layout to a data-warehouse/star topology for use with MySQL? I could see how a simpler table layout, particularly for mostly read-only operations, would make MySQL more appealing. (Firebird has a read-only mode in which transactions are ignored and things speed up, but we've never used it. All our reporting is done against the live database, up to the last committed transaction. Managers won't have it any other way.)
I thought I heard something about PG's "vacuum" being fixed/replaced in the near future, so the 24x7 thing won't be an issue anymore?
I was at Barnes & Noble tonight, waiting to go pick someone up at the airport. Looking through the tech-book section, apart from noticing a lack of theory books, I noticed that MySQL has done well for itself in the publishing world. SQL books most often refer to MySQL for examples, PHP books (and other "learn this language so you can incorrectly apply what you halfway learn to any problem you encounter" books) generally include a large section devoted to database stuff, seemingly always involving MySQL ... There were more MySQL books than Oracle books, more Oracle books than MS-SQL books, more of those than of PostgreSQL books, and no Firebird, MaxDB, Ingres, DB2, Cloudscape, HSQL, etc. books that I recall.
... you start to wonder why they don't use an RDBMS where they can express exactly what they mean, directly, and have it be fast. And MySQL's popularity has lead to a lot of people learning some very bad habits (particularly about doing a lot of client-side work, like joins or aggregates, or using sub-queries where joins should work) ... but people love it! (I think this is related to the stockholm syndrome, in a way; I also see it with data-entry clerks who are convinced that their crappy, buggy, expensive, old, vendor-supplied software is better than anything anyone will ever build, ever. If you're an in-house programmer, you're not a real programmer, either. Masochists.)
If most all programming were taught in Basic, don't you think people would wind up coding apps in Basic, regardless of its actual worthiness? (Today, it's Java, not Basic. But now I've called upon myself the wrath of the Java coders.)
I personally use Firebird at work and at home. Installation is a snap, particularly from binaries. Unpack, run installer, go. Works under *nix and windows, and has an embedded version appropriate for standalone apps. Its creator is the father of generational record-keeping (which some RDBMSs like MS-SQL have only recently gotten around to), and it's like an "easier to use under windows" cousin to PostgreSQL, feature-wise.
Other than good marketing (including a lot of word-of-mouth rumors) in favor of MySQL, I can't explain its success. When you have to help someone implement a query as a correlated sub-query because their RDBMS of choice (MySQL) doesn't do certain joins properly, or doesn't do them quickly (yes, even with indexing -- the optimizer is just stupid),
If that message happens to trigger a large financial transaction, that would be a bad thing.
... still.
Isn't this why we should be concerned with transactions, two-phase-commit, transaction managers, and asynchronous commit replies? Submit request, continue processing, and if you don't hear back about your commit for a while, do something about it? I dunno. If you want reliability, you need some way to audit your process to make sure things are actually happening as reported. Admittedly two-phase-commit has issues (ask any DBA who has to manually resync databases where limbo transactions have stacked up) but
There was an accepted standard of interoperating across the C calling convention. As long as various languages supported the standard calling convention (there's nothing special about the C one, almost any would do), libraries and code could be re-used (and use each other) without worrying about using whatever language someone else decided on. The bottom line is this: if I want to code in C and you want to code in Java and someone else wanted to use PHP and yet another person wanted to use Fortran or *shudder* Cobol, we shouldn't have to re-implement the libraries every time, we shouldn't have terribly convoluted mapping functionality to gain access to libraries (the JNI isn't exactly pretty) and we really shouldn't have to worry about it much at all.
The way we do things, our language wars are much more than just language wars: when someone argues for Java, they're also arguing (sometimes without realizing it) for all the already implemented Java libraries vs. libraries available by default in other languages. When you advocate Perl, you're also advocating CPAN. With PHP, you're advocating PEAR. Some of them internally re-use other libraries (particularly ones written in C) but that doesn't guarantee anything. Because of library incompatibilities, when you select a language, you have to do so based on the available code, not just on the language itself.
When you switch languages because something's easier or quicker or more obvious or readable or whatever in a language X, you shouldn't have to hunt down a whole new set of libraries that may or may not interface with equivalent libraries in the language you were just using, in turn meaning your apps can't (at least not easily) interoperate. So while I try to tell people there's nothing special about coding in C++, that it's not "better" than other languages, just easier for me to use and therefore my preferred tool, the truth is that if I switch languages for a particular chunk of a project, it's an enormous hassle to make things work together, and I'm not willing to deal with that.
It's vendor lock-in, and we happily go along with it. Sometimes it's just because language designers don't think of this as something they need to support, but in the case of companies like Sun or Microsoft, I think there's more to it.
It's entirely possible to write maintainable code in a language other than Java, programmers have been doing it for years. From my experience, it depends more on the programmer than the language -- whether or not you're able to think ahead, care about doing so, and do so usefully. And then document what you do, what you didn't do, and why. That's not much to ask, is it? Bugs happen in any language. Why not claim that laws make crimes (or even accidents) not happen?
For the OO definition: inheritance is vague. It means you keep at least the interface from one other class; it doesn't say whether or not you can get multiple interfaces from other classes, and it doesn't say whether or not you can get implementations of those interfaces from other classes (and if so, how many -- just 1, or several, or always all?).
The fact that you can do this means you can have dangling pointers, access violations, etc. like any other language that supports pointers at all. I'm just pointing out that there are ways of abusing the language. If you use pointers in C correctly, you won't have any problems either. If you use any language correctly, you'll not have any problems. If you use any language even remotely unsafe incorrectly, you can have problems. Most languages are at least slightly unsafe in one way or another; some allow you to turn off error checking, range checking, type checking, etc., sometimes even dynamically, around a single chunk of code, etc.
Why do people think of Pascal as inherently safe? If you want to mess with pointers, it's really rather easy. Stick 'em in a variant (union) record, do your arithmetic against another named integer, and there you go. I mean really ...
"Object-oriented programming" is ill-defined. It encompasses a lot of languages that go about it in entirely different ways. To me, the most it can mean is "calling functions with an assumed this pointer." What does OO mean to you? Virtuals? What makes it "real"?
There are benefits to C beyond speed and direct access to memory, hardware, etc. People seem to forget that for us to make software "work together", calling conventions across libraries need to be compatible. Which is why we picked C calling conventions. It's not necessarily the most expressive if you're into fancy things, but it is flexible enough for most everything. My main problem with Java isn't the language -- it's the libraries. Lots of them, packaged in their own special way, not really designed for use by any language.
Languages, most of the time, aren't the issue. We haven't gained all that many 'new' features with new languages, at least not anything we can't easily live without. Access to symbols is an issue, however, and a really important one from the point of view of integration, code re-use, and even making sure you're using trusted/proven code.
Regardless of buffer overflows, you can still write infinite loops, incorrect logic, etc. in just about any language. These language wars are about markets -- they're about money.
No. Your links point to the results of a 1000-phone-call survey of all ages (see age distribution at bottom of results). The results are still interesting (and made me very sad,) but they are not the same as those the grandparent was asking about.
Databases (typically relational) aren't just fast because of indices; they can also assume more about the structure of the data. A table (relation) is a set of tuples, each one with the same attributes, each one with a single value (however complex it might happen to be, in spite of what OODBMS people think.) When you've got that, you only need to store the meta-structure of the relation once, in the relation header. Then you can assume all sorts of stuff about what's to follow, and you can optimize the hell out of the data (CSV is so much more efficient than XML for transmitting relational data, it's amazing. And it's not even good.)
... things take a little longer. XML just doesn't have shortcuts for "and now some relational data" that can speed that up.
On the other hand, when you've got a document in which structure fluctuates wildly from item to item, and you have to look at the item to know what it might be (let alone
whether or not it's what you're looking for, what you can do with it, etc.)
Then again, when you're sending data, it seems redundant to send indices -- that's the sort of thing each receiving party should recreate as desired. But nobody said XML was about efficiency in reading/writing/searching/manipulating. It was about a standard, do-almost-anything, here's-a-prewritten-library-for-you, read-file-until-you-grok-it format. Efficiency's not in the list.
My girlfriend is often called out to people's homes to transfer their data to a new Dell (yeah, it's always a Dell). At some point a few months ago, she was asked to do this for a manager at a big tech company, who works from home. She didn't have the CD's with her for stuff like MS Project, so it couldn't be installed on the new computer. The files themselves, however, were copied. Rather than blaming herself for not having the CD's, or going out and buying a new one, she just complains that her files weren't copied. Application and Content are separate, but without the Application, people fail to understand that their Content has been copied. They don't understand why it's such a pain to try to copy Applications, obviously. Admittedly, it's less of a pain on, say, MasOS ... but Windows? Some software companies seem to delight in designing a maze of environment variables, registry keys, paths, dll's in random directories, etc. (But yes, Application == Content, it's all just bytes. Some are just easier to copy than others.)
Does a C API count? The Firebird project is open-source, has a .dll version of the server for embedding, and is written in C/C++ (they're converting everything over to C++ classes and exceptions.) It has a C API, for which you can find minimalist C++ wrappers. Firebird's footprint is really quite small, it's generally fast, it has good transaction semantics, good sql support, stored procedures, triggers, generators, ... it's sort of considered a cousin to PostgreSQL (they've concentrated on slightly different feature sets.)
Most people are too lazy to enter good metadata in webpages, even assuming a good, standard way of doing so. However I see some future in sites like GlobalSpec where your search is narrowed down until you know exactly what type of product you're looking for, and then extra metadata for that class of products is exposed in the search (usually in the form of sets of checkboxes and ranges of metric-aware values) -- allowing you to search by thread size on bolts, but not on other equipment where it's not relevant. I think some sort of community-driven version of this could be nice; let users create new types of attributes (or whole modules) for new types of 'items' and search using better metadata. Eh. It's an idea.
France has a system similar to this. At the end of 9th grade, you take a test (Brevet) to determine whether or not you're really fit for university studies. If you are, you go to a standard high school, and pick a specialty (language/arts, math, physics, biology, economics, etc.). You're expected to continue on to university studies in whatever specialty you've chosen. If you don't pass the test, you have the option of moving on to various tech-ish schools, again specializing into whatever field you seem interested in. You're not really expected to do university studies as a result, but you should be able to find a job. There's less stigma than with tech schools in the states, but still some. I had friends who went the alternate route, and though one got hired and trained in accounting right out of it, he still wasn't happy he hadn't made it into the "normal" high school. "Equal but separate" rarely works. Maybe if it were entirely up to the student (not based on scores) but even then ...
The fact that I'm not married but live with my girlfriend "hurts" my mother too, but that's no reason to throw me in a mental hospital or use laws to change my behavior. If we had to consider everyone who would be hurt or offended by our uses of personal liberty, we'd never get anywhere (there's always someone.) Your first argument was better than your second.
As to mental illness, I still find it offensive that we just (blanket-statement) declare those who attempt suicide to be mentally ill and no longer responsible for their actions, needing to be placed under someone's guardianship until they recover. We should be very careful with this sort of thinking. If we do this withouth thinking it through and carefully justifying our decisions, we're not very far away from the realm of "gays are mentally ill" or "rebels are mentally ill" or "communists are mentally ill". (It's not a slippery slope; but it's equally unjustified.)
"How could anyone in their right mind possibly do something like that?" is what you mean by "normal people [...] never do." It also means that someone who is terminally ill (say, with cancer or AIDS) is no longer allowed to make the decision to die slightly early to ease the pain. Obviously, they're mentally ill to wish such a thing, right? Maybe we should just drug them up some more until they can't tell what's going on; at least vegetables don't try to commit suicide.
The court would argue for the victim that no such oral contract existed, and require written, signed, notaried proof on the matter. Considering the apparent conflict of interest, the jury would likely not believe the defendant's claim about such an oral contract.
The point here is that children don't have the legal ability to make decisions like that, and parents can't do that for them either, generally. For example, a child can't generally consent to sex until fairly old, and parents certainly can't consent for them (or else all those cases of parents sexually abusing their children would suddenly get nixed.) Sure, we can change that, but it'll require rethinking all of our consent laws (and principles.) An emancipated child could make these decisions, yes. But the process of emancipation is rather odd. (Automatic vs. not; not letting children do to themselves that which is unsafe, etc.) How do we let a child make this decision for himself yet also give parents the right to tell their children 'no' to simple things like stabbing a pencil in their arm? Thoughts on the matter?
Our nation's economics are founded on the idea that we don't know what's best for us, and that relying on individually greedy, selfish people will get us the 'best' results by hit-and-miss. Since when do we enforce what's 'best' for us by law? (Okay, we try to, but since when is it also a good idea?)
As you pointed out in your other post, you need to show harm done by pornography. But not just to self. It's not a crime to be depressed or self-hating, for example. We've even upheld your right to commit suicide, and hurting yourself on purpose (cutting) is at most going to land you in a mental hospital while someone tries to figure out if you're sane enough to have rights or not. Does pornography hurt others, then?
How does pornography harm others? The only way it could is through the actions of individuals. And the only way we could blame porn itself is if in at least the extreme majority of cases, the individuals involved had lost all self-control and were no longer responsible for their actions. But even then, consider drugs. Just because being drunk makes you unable to maintain self-control doesn't mean that your actions are now alcohol's fault in general. It means it was your fault for abusing of the stuff in the first place, knowing what it would do to you. Porn's the same way. If you're not going to be able to maintain self-control if you're around porn, then it is your duty to avoid it; if you do not, you'll still be liable for whatever you wind up doing.
And hurting society? Laws shouldn't attempt to maintain the society however it was 'before'. Laws don't get re-approved at each generation, at each person being born. We are what we are. Over the course of human history, have our societies changed for the worse so much we have a clear example of it? The world's always going to hell in a handbasket, yet we never really seem to get any worse. If you read, say, the Meditations of Marcus Aurelius, you'll see his society was pretty much exactly like ours, no worse, no better. Do we need our laws to try to prevent natural, small shifts in every-day morality? It won't do any good. A few generations later, someone will get up the courage to change the laws, and your efforts will be for naught. You can make change more painful, but you can't prevent it. So should we try to mold our society, our culture, through law? No. We can, at any point in time, attempt to punish our citizens for harming each other, and that's about it.
Murdering someone (that is, killing them without their consent) deprives them of their ability to bring suit against you in court. The victim cannot bring charges, so the State (the People) feels it is dutiful to do that in place of the victim. The same should be true of any case where the victim cannot bring suit -- complete and utter lobotomy, permanent coma, etc.
Killing someone (including yourself) who has asked you to shouldn't be a crime, so long as that person has ability to give consent. A child's request for euthanasia should be ignored, for example. And there are some things parents can't consent to in the name of their children -- like dying.
However, even if our basis for creating laws is moral, law remains law -- by staying here past the age of majority, you consent to the laws of the land, regardless of their origin or nature. You agree to be punished for certain actions, and murder is one of them. Because law does not require that it be justified, it often is not. When states are particularly afraid they'll be accused of crossing some sort of church/state boundary, they'll just have a referendum instead -- let the people make the decision, so you don't need any justification whatsoever. Is it moral? Maybe. But the law doesn't encode that part.
Stargate: Atlantis should have been called Stargate: Voyager. I mean really; you've got a woman in charge of a group of people stranded on the far side of nowhere with no way back in a hostile environment (with the main enemy being some sort of slimy alien intent on human doom,) they pick up some locals to help guide them within the first episode, becoming grand pals ... and they're trying to be as funny as SG1 and are failing miserably. No, see, that might have worked for Star Trek, but I have a feeling SciFi's going to realize that it's not working for Stargate. And then we'll really be in trouble. (Just so long as they don't have a new prequel show too ...)
It's really too bad, in both cases. Enterprise and Atlantis both have interesting back stories to explore, giving our imaginations a bit more fuel for a while to come. Enterprise was going to give us the Federation -- with only one season to do it in, and having wasted a whole season talking about the war on terrorism (which they then did again, from the other point of view, with the vulcan episodes recently), I'm not seeing that getting done in time. Enterprise will be remembered as the ship with a couple of missions that never got around to doing its job of exploration, peace, etc. Atlantis hasn't gone far enough yet that an abrupt end would hurt the series as a whole, but it wouldn't take long -- just a few good stories and that's that.
P2P networks have had fairly good copies of Enterprise, at least, available within a week after airing. For those who could and would have watched it had it not been so badly placed (or had they not been out of town, or their equipment on the fritz,) that's a solution that doesn't involve DVR's. But it doesn't help the TV ratings.
The robot might have been "excessive", but it's useful in a proof-of-concept sort of way. Video is a 2d projection only; for something as complex as dance (can be), having an actual 3d recording of the moves is superior to a 2d recording. This could have been done with holograms, but recording the actual position of limbs is probably still superior to a visual recording of their position. This is a case where video is nice, but there are better ways of recording the underlying information. The robot is just a method of viewing this precise, not really ambiguous at all, data.
Not to flame, but the insinuation of my post was that most of the linux gui toolkits are mimicking windows -- and therefore failing to make true innovations, just improvements (which are great too, by the way.) If someone can point me to existing projects that (want to) do this, that'd be great. But as pointed out elsewhere -- like e17, who's going to change their apps over now to use some sort of semantic gui abstraction layer? The apps are written, we're locked in. We still keep pure X compatibility because of apps from decades ago that haven't switched to anything newer.
While we're at it -- isn't this all sugar anyway? Do we get more semantically-interesting constructs? I'm in the middle of building a new set of components for our existing application (it'll be a pain in the ass to go and fix all 500 screens, oh well) to be more semantically-aware. I don't want a "combo box" or an "edit box" -- I want a "select one item from this list of items / tree of items / graph of items" box, or a "decimal, positive number with a metric unit attached to it with automatic unit conversion" or any number of other data-aware components, not method-of-input-aware components. I don't think I get that with this set of updates, just "prettier" components. Anyone who cares enough, please feel free to correct me. But from my perspective, we should be working on semantic controls -- if the user prefers a set of radio buttons for small lists of items, so be it, so long as the end effect (selecing exactly one and returning the selection) stays the same. Got table data, or even some sort of multi-table in-memory database the user's looking at? Let them decide how they want to look at it, and give me, the programmer, the ability to do that for more than just my own app. It seems like a crime to still not have that by now ... Unix app, Mac app, DOS app, Windows app, it's all the same from a semantic point of view. There's data the user wants to see, and there's data we need from the user to do things -- who cares what it looks like on the programming side? *sigh* At least we've got database servers, filesystems, query/programming languages, and all that figured out. Wait. Nevermind. *sigh* Back to coding those components ...