I think you are missing the point. XML is good where you want to receive data from other systems over which you have no control. So it doesn't matter how good you are as a programmer, and how well you write YOUR program, the issue is that you've got cabbages (or programmers who resemble cabbages) upstream sending you data.
So XML is good for talking to systems that use XML, and not for actually developing efficient or usable software!
That's my whole point -- its only value is that it's some standard that replaced the situation when no common standard existed. Actual quality of its design is still crap, it's written by wrong people, derived from wrong theoretical base and is implementing using wrong tools and techniques. I am not claiming that it's completely unusable, or that people shouldn't use it for user-oriented applications and interoperability. I claim that the quality of the standard is total shit, and people who developed it are self-serving, ideologically blinded, dishonest, incompetent hacks, so no wonder that those who actually needed a good data interchange format had to sevelop something different.
And your evidence of this assertion is...what exactly?
The fact that I didn't sleep through compiler classes, and therefore know that a parser is an extremely simple piece of software. XML is only useful if you want to use XML parser, and the actual design of the format is at about the same level of quality as Fortran syntax. Likely for the same reason -- Fortran predates widespread knowledge of parsers, so it was made to be so cumbersome, a person who does not understand what a parser is still can write a parser for it.
Not to mention the minor detail that XML and compilers are orthogonal: you can use XML (or many other data interchange formats) with non-compiled languages, and most compilers know nothing about XML (or many other data interchange formats).
Any procedure that converts structured serialized data into any other format is by definition a parser. Parsers are usually studied in compiler-related classes, however same concepts and designs apply to all parsers.
And your evidence of this assertion is...what exactly? XML-consuming programs that are aware of the data structure can have as detailed a "reaction to a failure" as a JSON-consuming program, or a YAML-consuming program, or a Protocol Buffer-consuming program.
And all of them "check" the format, wasting CPU time, memory and cache, then can do nothing but crash (oh, sorry, throw exception for which there is no valid logic to handle) in the impossible case of format being invalid, and doing nothing if the actual data is semantically invalid (because semantic processing is done by a program written by a programmer who knows that it can't verify the data). Validation solves the problem that does not exist, it makes as much sense as accompanying data structures in memory with a CRC -- if it ever does not match, what are you going to do, send a message "Stand by for imminent crash" into the log? It's a completely wrong place for verification unless your application development model is "perma-debugging".
XML-consuming programs that are not aware of the data structure can, if the XML supplies it, validate against a DTD or schema, things which are not possible in some other data interchange formats (e.g., JSON, YAML).
DTD and schema contain no semantic information. Semantics (actual meaning of data for application) is what the application has to process and possibly validate, it's too late to react if things are so screwed up that syntax is invalid, your application would be dead at that point already.
All data comes in neatly packaged buckets of varying types. We call them "bytes" and "packets" and "structures" and "records" and "frames" and "rows" and the like. The only way I can interpret your claim in a way that makes sense is to translate it as "XML sucks for streaming audio and video", which is undoubtedly true, and I don't think anyone uses it in that arena.
XML sucks for streaming data. Most of the data in anything that actually used for some practical purpose is of a "streaming" kind, request-response cycle is more often an exception than a rule. It only became popular because it's easy to implement with crappy tools.
On the contrary, this is one of XML's primary strengths -- handling cases where programs lack the "same knowledge of message semantics".
By definition, if you don't know semantics, data is meaningless (get it -- semantics, meaning). All you can do is to resend, filter or display the data, what illustrates my point -- it's good for displaying pretty pictures to the user, bad for doing actual processing work.
For centuries people burned forests to get patches of land that remained suitable for agriculture for a few years before moving to another patch. It worked, too. This does not mean that such barbaric practice was not a result of fundamental ignorance, or that it would be acceptable in a modern society.
Same applies to "technologies" such as XML -- except, of course, primitive agriculture had far more excuses to be used at its time than XML has now.
XML is absolutely definitely a format -- eXtensible Markup Language.
The facts that this is not an actual language but an umbrella format for multiple incompatible and non-discoverable XML-based formats, and that it's so crappy that a whole industry was grown out of building support for a single type of data structure (tree, not even an arbitrary graph that real-world data is) represented in it, only emphasizes a massive engineering failure that it is.
You still have all conversion routines built into language support, so all non-Unicode charsets still carry their support code into software. And it would be very easy to switch between charsets -- this happens anyway when you deal with character ranges that are not present in the fonts you use for your output. It all happens behind the scenes anyway.
The problem is, XML developers' Unicode fanaticism threw all this flexibility out of the window on the level of document data and metadata processing, keeping all complexity and sabotaging functionality, just to leave implementors and users no choice but to convert everything to Unicode.
This came at a pretty high price -- "simplified" processing allowed to handle text as if languages don't matter, so whenever I write a document in both Russian and English I actually get either document in English with sequences of Cyrillic characters that look like Russian words, or document in Russian with sequences of Roman characters that look like English words (as opposed to, say, Roman characters in Russian-only text that contains formulas).
Everything that is capable of editing or processing XML will make no attempt to let me choose the languages, so support for language-dependent processing is just as missing as support for charset-dependent processing, it's all Unicode, right? Except, of course, Unicode will do nothing to tell the application to choose right capitalization procedure, spellchecker, hyphenation, phonetic match, acronym expansion, index sorting, etc. -- "simplification" only made sense if it turned language handling into a superficial imitation of itself. If support for multiple charsets was included, it would automatically have to properly process all metadata including languages, and it would be able to use non-Unicode-oriented language-specific routines that existed for decades before Unicode.
So this is what Unicode produced -- it allowed to write software that looks like it draws all those pretty characters, but in fact does not handle languages in a way that a native speaker would recognize them as such. Good job, indeed.
Actually it handles languages EXTREMELY POORLY, because one of the design goal was to make Unicode mandatory. If XML was truly designed for handling multilingual data, every tag would be able to have attributes for language, charset and encoding, and those tags would default to "undefined, treat as opaque", to ensure safe round trip of untagged data from/to other formats.
Now it's impossible to use non-Unicode charsets when using multiple languages in the same program because THE WHOLE FREAKING DOCUMENT (why is it even mandatory to have "document"? Log file, for example, may contain records that should be readable before the file reached it final length -- if it is written in XML, it's formally invalid until the last moment when the logger stopped writing to it and closed its last tag even though it has no semantic meaning for the log that is a collection of records and records only) has to have one and only one charset/encoding even though it can contain text in multiple languages. Since most charsets only support one or few related languages, all implementations of XML-using software ended up hardcoding Unicode as the only supported charset.
1. Easy parsing by parsers written by people who slept through their compiler classes.
2. Verification in situations when it's impossible to devise a meaningful reaction to a failure (other than either "everything failed, turn off the computers and go home" and "assume the data to be valid anyway because ALL of it will have the same formatting error because the same program generates it")
3. Dealing with data that arrives in neatly packaged "documents" and "requests", as opposed to being constantly produced and consumed.
4. Either communicating between programs that have the same knowledge of message semantics, or preparation of pretty human-readable documents.
None of the above even remotely applies to anything practical except UI/display formats -- this is why XHTML and ODF (and because of that at some extent XSL) are usable, SOAP is a load of crap, and for the rest of purposes XML is used as a glorified CSL with angle brackets. XML is widespread because monumentally stupid standard is still better than no standard.
So here is your example of how superior can be ANY format that is not based on this stupid idea.
This still doesn't change the fact that he was convicted without evidence. It can only get more embarrassing for the court if it will turn out that most of supposedly incriminating evidence (blood, etc.) is actually unrelated.
As an aside, I do not think that you are being rigorously honest with yourself when you say that Hans "just let it off the leash for a few minutes." Do your really believe that he didn't think, obsess, and dwell on about killing his wife before he actually did it? Come on. He stoked his rage, stoked it some more, then acted on it. This is Murder 1, not Murder 2.
If he actually planned it, he would do something to actively divert the blame from himself before killing her. There was nothing that suggests that he performed any kind of preparation, only things that can be interpreted as Hans clumsily covering his tracks after the fact (or as Hans being afraid for unrelated reasons), so unless police and prosecutor are even dumber than they shown themselves to be, he did not plan it.
The problem is, if there was anything actually proven in that mockery of a court, it was that Hans was a moderate asshole and Nina was a massive bitch, scammer, embezzler and adulteress who caused nothing but harm to the rest of society -- Hans and her kids included. Too bad, neither of those two facts was relevant to determining the facts of the crime.
Congratulations, Americans -- your justice system relies on lucky guesses and the hope that less charming people are more likely to be criminals.
The fundamental idea of property is that owner has absolute control over using it in all kinds of transactions, with state specifically limiting it in a small amount of cases where transaction would conflict with function of society. Often the owner has little or no direct control of his property's functions -- for example, land owner may be incapable of performing any agricultural work on it, or even unable to physically reach it. Ownership exists as a legally established control, and would be reduced to nothing if it is not recognized by other people and not enforced by the state.
With your body you have pretty much no ability to use it directly in any contract -- it's an unalienable part of yourself, and not a subject of trade. On the other hand, regardless of any legal fiction or even your own desires you have direct physical control over it. Even if you were a slave you would still physically control your body as long as you are alive and your body is capable of performing its functions. Nothing that creates, limits or revokes ownership can change the fact that you exist in your body.
If progress of technology will at some point allow people to create artificial bodies and move between them, it is possible that some form of ownership should be established for "unoccupied" bodies -- something has to regulate which person can move into those bodies because there would be more than one possible candidate for it. Even then a person would still have to have at least one body to remain alive, and depriving him of direct control of that body would kill, imprison or enslave him, so such transaction would be still illegal in any sane society.
You can't rent yourself -- a contract that would allow someone to do "anything" with your body would be invalid.
You can rent your labor what is not the same as renting your body. In fact, nothing prevents you from renting a labor that you perform with tools that you don't own, or even with prosthetic replacements for your body parts that you may or may not own -- your body's involvement in your labor is not relevant, your control over performing your labor is.
If you actually owned your person, it would be possible to demand it as your property in payments for debts, so debt slavery would be legal.
The truth is, property ownership is only a foundation of economic freedoms. Most of those "economic freedoms" are based on establishing ways to control other people through control of property, and therefore I find nothing positive or worth supporting about them.
You can criticize Communists until the cows come home, but they were right about this fundamental thing -- property that establishes control allows to obtain more property from controlled people, and serves against the interests of the majority of society. Something that eliminates this control without actually depriving people from use of that property is the perfect solution to this problem -- except, of course, it pisses off people who feel entitled to control of other people and don't use property for any other purpose.
When Ubuntu Hardy was being released in April, I have posted installation instructions for it on XO. This is still probably the best way to install a "mainstream" Linux distribution on that laptop -- XO has rather unusual screen pixels layout with 1200x900 "visible" resolution, so Xubuntu desktop with a GTK theme made to accommodate XO's unusual screen behavior is better suited for it than a desktop made for plain low resolution and mostly touchscreen input that XO does not have.
If attorneys could see through fallacies of their arguments nearly as well as programmers see possible failure conditions of their programs, they would never show up in a court.
This is how things worked in early 80's, when programmers mostly used two programming languages -- assembler and Fortran. Then the tediousness of coding was so great, it was possible to imagine that a person who can design a program may be incapable of implementing it.
Now it means that he is plain incompetent, and shouldn't be involved in software development in the first place.
If you know COBOL or FORTRAN, you are employed, too -- because very few people can put up with that crap. That doesn't mean, those languages are not hopelessly obsolete -- and yes, I know that modern versions of Fortran are still popular for scientific calculations because of massive inertia.
Same about crappy "middleware", except in particular case of Sharepoint, it is mostly promoted by consultants, what means that you are employed for twice normal rate 1/3 of the time and unemployed for the rest.
A work of art made in a different time period may still be inferior to the original in a way that affects the impression it makes on its viewer. This has nothing to do with "originality" but with consistency of author's expression -- say, if I was painting Sistine Chapel, I would include a full set of lolcats, a person pretending to use a celphone, God writing a letter to Flying Spaghetti Monster discussing piracy, and other things that make perfect sense for me in the context of modern culture but would be meaningless or offensive (not to mention, blasphemous) in 16th century. A person who would want to understand a mindset of someone living 500 years ago would get a much better idea of what it was by looking at the original chapel than from my version. However given that I had a talent comparable to Michelangelo, and put a comparable amount of effort, my chapel would be a great work of modern art, possibly with significance that surpasses actual Sistine Chapel.
So yes, historical value exists in a way that original work provides accuracy both in style (no matter what, we are absolutely sure, Sistine Chapel is 100% lolcat-free, what can't be guaranteed for any modern work) and material (we can study a broad range of things from paints composition to politics and society that produced a chapel covered with frescos). A different question would be, just how close is it to the current prices for historic pieces of art. For most of them my answer would be "nowhere close" -- traditional art prices were formed when truly indistinguishable reproduction was nearly impossible, so anything but original would not produce just the same impression.
Without modern photography devaluing the details, realistic depiction of small, hard to reproduce minor pieces of background was a statement in itself, emphasizing importance of the work for the artist, its connection to his perception of real life. Now, when everyone knows that I can press a button on a camera and paste perfectly realistic background into a digital drawing or trace it with a pencil, a presence of it means almost nothing even if I will bother making it the old-fashioned way -- a choice of things to emphasize is far more important than life-imitation of random details. Among other things, this made art easier to reproduce -- both in prints (lower dynamic range of colors and lack of texture don't lose anything significant) and in imitation using the original medium (less stuff to re-do, easier to concentrate on things that have to be reproduced correctly).
So why art is still expensive beyond its historical value? As a holdover from times when high-quality reproduction of anything with artistic value was unreasonably difficult, and because art is treated as a sort of currency, collector item not unlike baseball cards, objects with nearly zero value of any kind, priced entirely based on its verifiable uniqueness. What is, of course, contrary to the purpose of the art that exists to be seen by people, not hidden in an attempt to preserve it.
But then, we have copies to look at. In many situations copies are actually superior to the original in a way that was the reason for having the original -- faithful reproduction of author's intent and work. Paints deteriorate, buildings need repairs, parks get surrounded by structures in incompatible styles, get affected by pollution and changes in local ecosystem, etc. Restoration that would make them produce the original impression on the viewer may be impossible, or destroy other valuable qualities of the original such as materials being available for study or presence of undiscovered details of structure (ex: Egyptian pyramids, and their system of passages and tunnels). But reproduction can reflect the original state, a way how the piece of art was seen after it was originally made, and this may be more valuable for a modern viewer than a deteriorated copy.
Cancer, of course. First of all, he deserves nothing less. Second, it would be nice to see how he will still choose to stroke his own ego by running his foundation and dangling money in front of people far superior to himself, as opposed to letting competent people to run cancer research that would have a chance to cure him.
I use diagrams. Usually two per subsystem. However when I do it, I do pretty much everything in a way, opposite to what diagram-lovers are accustomed to.
The principles are:
1. Diagram is an illustration. It does not represent the code because any diagram properly representing any kind of real-life code would be too complex to be readable. It only makes sense to use diagrams to illustrate documentation where some part of it are more readable in a graphical form.
2. Diagram should be very clear about what it actually represents. If it's a state, make sure that it captures a moment in time and maybe possible outcome -- for the new state draw another diagram. If it represents dependencies, make sure that all dependencies can be derived from it. If it represents relationships, communications, data structures, etc. make sure that types of objects, relationships, etc. are clearly distinguished from each other. If an arrow represents pointer, reference or mapping, another arrow that represents data flow or message transfer SHOULD BETTER LOOK NOWHERE CLOSE to the first one. No one cares if they are all one-to-one or one-to-many -- what is important, they are fundamentally different things. If you ran out of arrow types, draw a line with a penis on its end -- it means your diagram is too complex to be helpful to other people anyway.
3. Despite all this clarity, it should be clear that diagram is an informal drawing that illustrates your specification or code. It is not a language. It does not contain everything necessary for implementation of your software. You can't use it to generate anything. It does not matter what tool generated it -- it's a picture. You still have to write clear documentation.
4. If it makes sense (it usually does), represent multiple entities in lists as 2-3 examples with an ellipsis between them, add torn edges to tables, etc. to show a usable example of how your system deals with complex data, communications, etc.
5. Finite state machines usually have more states than you thought. Much more. Last two times I have seen proper representation of a finite state machine as a diagram were diagrams of TCP connection states and example diagrams of language scanners for compilers. If everything was FSM, people would never invent dynamic memory allocation. In reality you most likely have to deal with objects participating in a complex systems of relationships with other objects, each such relationship having its own state, and object as a whole having its "state" derived from all of them. An attempt to draw a "FSM" diagram for this kind of system usually creates a very misleading view of how things behave in reality, encouraging wrong data models, race conditions, severe underestimation of resources usage, memory leaks, etc.
6. Last time people had any hope to use flowcharts for something useful was in 70's. And those were people who programmed exclusively in assembly language and Fortran. And by Fortran I mean Fortran IV. Have you tried to understand an algorithm implemented in Fortran IV? You would think, flowchart is a better representation, too, but it's actually wrong -- a better representation would be pseudocode. Procedural languages such as C and Pascal, and later object-oriented languages made pseudocode unnecessary.
7. There are really a lot of things that no one cares about, and even less so wants to see in a diagram form. Imagine a large ractangle labeled "libc", with a tree growing out of it with include files, groups of functions, functions and arguments attached to them. Have you seen it when studying C and libc? Do you know why you didn't? That's right, because it would be a confusing mess, distracting from both syntax and functionality, emphasizing superficial over essential. Your project does not need it any more than libc does.
8. Use simple tools that allow you to concentrate on readability, not completeness or compliance with a standard that makes you pretend that your diagram is formal and not informal part of documentation. XFig, Inksc
Here is an illustration of what I meant in my earlier comment. Instead of having a law that specifies precisely what punishment corresponds to a common and unremarkable crime we have on one hand ridiculous pileup of multiple charges for the same actions, and on the other hand, without any doubt, attorney claiming that it's all total bullshit, parole slashing prison terms to nearly nothing, etc. Let the shouting match begin, and expect a completely random result that has nothing to do with severity of the crime, deterrence, common sense and least of all -- justice.
Slashdot Mirror
I think you are missing the point. XML is good where you want to receive data from other systems over which you have no control. So it doesn't matter how good you are as a programmer, and how well you write YOUR program, the issue is that you've got cabbages (or programmers who resemble cabbages) upstream sending you data.
So XML is good for talking to systems that use XML, and not for actually developing efficient or usable software!
That's my whole point -- its only value is that it's some standard that replaced the situation when no common standard existed. Actual quality of its design is still crap, it's written by wrong people, derived from wrong theoretical base and is implementing using wrong tools and techniques. I am not claiming that it's completely unusable, or that people shouldn't use it for user-oriented applications and interoperability. I claim that the quality of the standard is total shit, and people who developed it are self-serving, ideologically blinded, dishonest, incompetent hacks, so no wonder that those who actually needed a good data interchange format had to sevelop something different.
And your evidence of this assertion is...what exactly?
The fact that I didn't sleep through compiler classes, and therefore know that a parser is an extremely simple piece of software. XML is only useful if you want to use XML parser, and the actual design of the format is at about the same level of quality as Fortran syntax. Likely for the same reason -- Fortran predates widespread knowledge of parsers, so it was made to be so cumbersome, a person who does not understand what a parser is still can write a parser for it.
Not to mention the minor detail that XML and compilers are orthogonal: you can use XML (or many other data interchange formats) with non-compiled languages, and most compilers know nothing about XML (or many other data interchange formats).
Any procedure that converts structured serialized data into any other format is by definition a parser. Parsers are usually studied in compiler-related classes, however same concepts and designs apply to all parsers.
And your evidence of this assertion is...what exactly? XML-consuming programs that are aware of the data structure can have as detailed a "reaction to a failure" as a JSON-consuming program, or a YAML-consuming program, or a Protocol Buffer-consuming program.
And all of them "check" the format, wasting CPU time, memory and cache, then can do nothing but crash (oh, sorry, throw exception for which there is no valid logic to handle) in the impossible case of format being invalid, and doing nothing if the actual data is semantically invalid (because semantic processing is done by a program written by a programmer who knows that it can't verify the data). Validation solves the problem that does not exist, it makes as much sense as accompanying data structures in memory with a CRC -- if it ever does not match, what are you going to do, send a message "Stand by for imminent crash" into the log? It's a completely wrong place for verification unless your application development model is "perma-debugging".
XML-consuming programs that are not aware of the data structure can, if the XML supplies it, validate against a DTD or schema, things which are not possible in some other data interchange formats (e.g., JSON, YAML).
DTD and schema contain no semantic information. Semantics (actual meaning of data for application) is what the application has to process and possibly validate, it's too late to react if things are so screwed up that syntax is invalid, your application would be dead at that point already.
All data comes in neatly packaged buckets of varying types. We call them "bytes" and "packets" and "structures" and "records" and "frames" and "rows" and the like. The only way I can interpret your claim in a way that makes sense is to translate it as "XML sucks for streaming audio and video", which is undoubtedly true, and I don't think anyone uses it in that arena.
XML sucks for streaming data. Most of the data in anything that actually used for some practical purpose is of a "streaming" kind, request-response cycle is more often an exception than a rule. It only became popular because it's easy to implement with crappy tools.
On the contrary, this is one of XML's primary strengths -- handling cases where programs lack the "same knowledge of message semantics".
By definition, if you don't know semantics, data is meaningless (get it -- semantics, meaning). All you can do is to resend, filter or display the data, what illustrates my point -- it's good for displaying pretty pictures to the user, bad for doing actual processing work.
For centuries people burned forests to get patches of land that remained suitable for agriculture for a few years before moving to another patch. It worked, too. This does not mean that such barbaric practice was not a result of fundamental ignorance, or that it would be acceptable in a modern society.
Same applies to "technologies" such as XML -- except, of course, primitive agriculture had far more excuses to be used at its time than XML has now.
XML is absolutely definitely a format -- eXtensible Markup Language.
The facts that this is not an actual language but an umbrella format for multiple incompatible and non-discoverable XML-based formats, and that it's so crappy that a whole industry was grown out of building support for a single type of data structure (tree, not even an arbitrary graph that real-world data is) represented in it, only emphasizes a massive engineering failure that it is.
You still have all conversion routines built into language support, so all non-Unicode charsets still carry their support code into software. And it would be very easy to switch between charsets -- this happens anyway when you deal with character ranges that are not present in the fonts you use for your output. It all happens behind the scenes anyway.
The problem is, XML developers' Unicode fanaticism threw all this flexibility out of the window on the level of document data and metadata processing, keeping all complexity and sabotaging functionality, just to leave implementors and users no choice but to convert everything to Unicode.
This came at a pretty high price -- "simplified" processing allowed to handle text as if languages don't matter, so whenever I write a document in both Russian and English I actually get either document in English with sequences of Cyrillic characters that look like Russian words, or document in Russian with sequences of Roman characters that look like English words (as opposed to, say, Roman characters in Russian-only text that contains formulas).
Everything that is capable of editing or processing XML will make no attempt to let me choose the languages, so support for language-dependent processing is just as missing as support for charset-dependent processing, it's all Unicode, right? Except, of course, Unicode will do nothing to tell the application to choose right capitalization procedure, spellchecker, hyphenation, phonetic match, acronym expansion, index sorting, etc. -- "simplification" only made sense if it turned language handling into a superficial imitation of itself. If support for multiple charsets was included, it would automatically have to properly process all metadata including languages, and it would be able to use non-Unicode-oriented language-specific routines that existed for decades before Unicode.
So this is what Unicode produced -- it allowed to write software that looks like it draws all those pretty characters, but in fact does not handle languages in a way that a native speaker would recognize them as such. Good job, indeed.
Actually it handles languages EXTREMELY POORLY, because one of the design goal was to make Unicode mandatory. If XML was truly designed for handling multilingual data, every tag would be able to have attributes for language, charset and encoding, and those tags would default to "undefined, treat as opaque", to ensure safe round trip of untagged data from/to other formats.
Now it's impossible to use non-Unicode charsets when using multiple languages in the same program because THE WHOLE FREAKING DOCUMENT (why is it even mandatory to have "document"? Log file, for example, may contain records that should be readable before the file reached it final length -- if it is written in XML, it's formally invalid until the last moment when the logger stopped writing to it and closed its last tag even though it has no semantic meaning for the log that is a collection of records and records only) has to have one and only one charset/encoding even though it can contain text in multiple languages. Since most charsets only support one or few related languages, all implementations of XML-using software ended up hardcoding Unicode as the only supported charset.
I always told people that -- it's optimized for:
1. Easy parsing by parsers written by people who slept through their compiler classes.
2. Verification in situations when it's impossible to devise a meaningful reaction to a failure (other than either "everything failed, turn off the computers and go home" and "assume the data to be valid anyway because ALL of it will have the same formatting error because the same program generates it")
3. Dealing with data that arrives in neatly packaged "documents" and "requests", as opposed to being constantly produced and consumed.
4. Either communicating between programs that have the same knowledge of message semantics, or preparation of pretty human-readable documents.
None of the above even remotely applies to anything practical except UI/display formats -- this is why XHTML and ODF (and because of that at some extent XSL) are usable, SOAP is a load of crap, and for the rest of purposes XML is used as a glorified CSL with angle brackets. XML is widespread because monumentally stupid standard is still better than no standard.
So here is your example of how superior can be ANY format that is not based on this stupid idea.
This still doesn't change the fact that he was convicted without evidence. It can only get more embarrassing for the court if it will turn out that most of supposedly incriminating evidence (blood, etc.) is actually unrelated.
As an aside, I do not think that you are being rigorously honest with yourself when you say that Hans "just let it off the leash for a few minutes." Do your really believe that he didn't think, obsess, and dwell on about killing his wife before he actually did it? Come on. He stoked his rage, stoked it some more, then acted on it. This is Murder 1, not Murder 2.
If he actually planned it, he would do something to actively divert the blame from himself before killing her. There was nothing that suggests that he performed any kind of preparation, only things that can be interpreted as Hans clumsily covering his tracks after the fact (or as Hans being afraid for unrelated reasons), so unless police and prosecutor are even dumber than they shown themselves to be, he did not plan it.
Way to paint the victim as the villain.
The problem is, if there was anything actually proven in that mockery of a court, it was that Hans was a moderate asshole and Nina was a massive bitch, scammer, embezzler and adulteress who caused nothing but harm to the rest of society -- Hans and her kids included. Too bad, neither of those two facts was relevant to determining the facts of the crime.
Congratulations, Americans -- your justice system relies on lucky guesses and the hope that less charming people are more likely to be criminals.
The fundamental idea of property is that owner has absolute control over using it in all kinds of transactions, with state specifically limiting it in a small amount of cases where transaction would conflict with function of society. Often the owner has little or no direct control of his property's functions -- for example, land owner may be incapable of performing any agricultural work on it, or even unable to physically reach it. Ownership exists as a legally established control, and would be reduced to nothing if it is not recognized by other people and not enforced by the state.
With your body you have pretty much no ability to use it directly in any contract -- it's an unalienable part of yourself, and not a subject of trade. On the other hand, regardless of any legal fiction or even your own desires you have direct physical control over it. Even if you were a slave you would still physically control your body as long as you are alive and your body is capable of performing its functions. Nothing that creates, limits or revokes ownership can change the fact that you exist in your body.
If progress of technology will at some point allow people to create artificial bodies and move between them, it is possible that some form of ownership should be established for "unoccupied" bodies -- something has to regulate which person can move into those bodies because there would be more than one possible candidate for it. Even then a person would still have to have at least one body to remain alive, and depriving him of direct control of that body would kill, imprison or enslave him, so such transaction would be still illegal in any sane society.
This is one of situations where all I can say is:
If your problem requires this solution, then it is actually unsolvable, and you are all screwed.
You can't rent yourself -- a contract that would allow someone to do "anything" with your body would be invalid.
You can rent your labor what is not the same as renting your body. In fact, nothing prevents you from renting a labor that you perform with tools that you don't own, or even with prosthetic replacements for your body parts that you may or may not own -- your body's involvement in your labor is not relevant, your control over performing your labor is.
I own my person
If you actually owned your person, it would be possible to demand it as your property in payments for debts, so debt slavery would be legal.
The truth is, property ownership is only a foundation of economic freedoms. Most of those "economic freedoms" are based on establishing ways to control other people through control of property, and therefore I find nothing positive or worth supporting about them.
You can criticize Communists until the cows come home, but they were right about this fundamental thing -- property that establishes control allows to obtain more property from controlled people, and serves against the interests of the majority of society. Something that eliminates this control without actually depriving people from use of that property is the perfect solution to this problem -- except, of course, it pisses off people who feel entitled to control of other people and don't use property for any other purpose.
When Ubuntu Hardy was being released in April, I have posted installation instructions for it on XO. This is still probably the best way to install a "mainstream" Linux distribution on that laptop -- XO has rather unusual screen pixels layout with 1200x900 "visible" resolution, so Xubuntu desktop with a GTK theme made to accommodate XO's unusual screen behavior is better suited for it than a desktop made for plain low resolution and mostly touchscreen input that XO does not have.
I have posted videos of this version of Ubuntu in action on Youtube, and photos of the installation procedure (still with old GTK theme) on my Livejorunal.
Refering to a bunch of companies as "Big N" is American-ism, so none of those companies qualify.
Unrelated to that, the company that makes Lada is VAZ or AVTOVAZ, so it's neither "big" nor has a four-letter name.
If attorneys could see through fallacies of their arguments nearly as well as programmers see possible failure conditions of their programs, they would never show up in a court.
you can easily make good money contracting in large metro areas.
Just keep yourself away from any decent programmers.
There are no "business analysts" anymore. Thankfully.
This is how things worked in early 80's, when programmers mostly used two programming languages -- assembler and Fortran. Then the tediousness of coding was so great, it was possible to imagine that a person who can design a program may be incapable of implementing it.
Now it means that he is plain incompetent, and shouldn't be involved in software development in the first place.
If you know COBOL or FORTRAN, you are employed, too -- because very few people can put up with that crap. That doesn't mean, those languages are not hopelessly obsolete -- and yes, I know that modern versions of Fortran are still popular for scientific calculations because of massive inertia.
Same about crappy "middleware", except in particular case of Sharepoint, it is mostly promoted by consultants, what means that you are employed for twice normal rate 1/3 of the time and unemployed for the rest.
A work of art made in a different time period may still be inferior to the original in a way that affects the impression it makes on its viewer. This has nothing to do with "originality" but with consistency of author's expression -- say, if I was painting Sistine Chapel, I would include a full set of lolcats, a person pretending to use a celphone, God writing a letter to Flying Spaghetti Monster discussing piracy, and other things that make perfect sense for me in the context of modern culture but would be meaningless or offensive (not to mention, blasphemous) in 16th century. A person who would want to understand a mindset of someone living 500 years ago would get a much better idea of what it was by looking at the original chapel than from my version. However given that I had a talent comparable to Michelangelo, and put a comparable amount of effort, my chapel would be a great work of modern art, possibly with significance that surpasses actual Sistine Chapel.
So yes, historical value exists in a way that original work provides accuracy both in style (no matter what, we are absolutely sure, Sistine Chapel is 100% lolcat-free, what can't be guaranteed for any modern work) and material (we can study a broad range of things from paints composition to politics and society that produced a chapel covered with frescos). A different question would be, just how close is it to the current prices for historic pieces of art. For most of them my answer would be "nowhere close" -- traditional art prices were formed when truly indistinguishable reproduction was nearly impossible, so anything but original would not produce just the same impression.
Without modern photography devaluing the details, realistic depiction of small, hard to reproduce minor pieces of background was a statement in itself, emphasizing importance of the work for the artist, its connection to his perception of real life. Now, when everyone knows that I can press a button on a camera and paste perfectly realistic background into a digital drawing or trace it with a pencil, a presence of it means almost nothing even if I will bother making it the old-fashioned way -- a choice of things to emphasize is far more important than life-imitation of random details. Among other things, this made art easier to reproduce -- both in prints (lower dynamic range of colors and lack of texture don't lose anything significant) and in imitation using the original medium (less stuff to re-do, easier to concentrate on things that have to be reproduced correctly).
So why art is still expensive beyond its historical value? As a holdover from times when high-quality reproduction of anything with artistic value was unreasonably difficult, and because art is treated as a sort of currency, collector item not unlike baseball cards, objects with nearly zero value of any kind, priced entirely based on its verifiable uniqueness. What is, of course, contrary to the purpose of the art that exists to be seen by people, not hidden in an attempt to preserve it.
But then, we have copies to look at. In many situations copies are actually superior to the original in a way that was the reason for having the original -- faithful reproduction of author's intent and work. Paints deteriorate, buildings need repairs, parks get surrounded by structures in incompatible styles, get affected by pollution and changes in local ecosystem, etc. Restoration that would make them produce the original impression on the viewer may be impossible, or destroy other valuable qualities of the original such as materials being available for study or presence of undiscovered details of structure (ex: Egyptian pyramids, and their system of passages and tunnels). But reproduction can reflect the original state, a way how the piece of art was seen after it was originally made, and this may be more valuable for a modern viewer than a deteriorated copy.
What would you buy him as a retirement gift?
Cancer, of course. First of all, he deserves nothing less. Second, it would be nice to see how he will still choose to stroke his own ego by running his foundation and dangling money in front of people far superior to himself, as opposed to letting competent people to run cancer research that would have a chance to cure him.
I use diagrams. Usually two per subsystem. However when I do it, I do pretty much everything in a way, opposite to what diagram-lovers are accustomed to.
The principles are:
1. Diagram is an illustration. It does not represent the code because any diagram properly representing any kind of real-life code would be too complex to be readable. It only makes sense to use diagrams to illustrate documentation where some part of it are more readable in a graphical form.
2. Diagram should be very clear about what it actually represents. If it's a state, make sure that it captures a moment in time and maybe possible outcome -- for the new state draw another diagram. If it represents dependencies, make sure that all dependencies can be derived from it. If it represents relationships, communications, data structures, etc. make sure that types of objects, relationships, etc. are clearly distinguished from each other. If an arrow represents pointer, reference or mapping, another arrow that represents data flow or message transfer SHOULD BETTER LOOK NOWHERE CLOSE to the first one. No one cares if they are all one-to-one or one-to-many -- what is important, they are fundamentally different things. If you ran out of arrow types, draw a line with a penis on its end -- it means your diagram is too complex to be helpful to other people anyway.
3. Despite all this clarity, it should be clear that diagram is an informal drawing that illustrates your specification or code. It is not a language. It does not contain everything necessary for implementation of your software. You can't use it to generate anything. It does not matter what tool generated it -- it's a picture. You still have to write clear documentation.
4. If it makes sense (it usually does), represent multiple entities in lists as 2-3 examples with an ellipsis between them, add torn edges to tables, etc. to show a usable example of how your system deals with complex data, communications, etc.
5. Finite state machines usually have more states than you thought. Much more. Last two times I have seen proper representation of a finite state machine as a diagram were diagrams of TCP connection states and example diagrams of language scanners for compilers. If everything was FSM, people would never invent dynamic memory allocation. In reality you most likely have to deal with objects participating in a complex systems of relationships with other objects, each such relationship having its own state, and object as a whole having its "state" derived from all of them. An attempt to draw a "FSM" diagram for this kind of system usually creates a very misleading view of how things behave in reality, encouraging wrong data models, race conditions, severe underestimation of resources usage, memory leaks, etc.
6. Last time people had any hope to use flowcharts for something useful was in 70's. And those were people who programmed exclusively in assembly language and Fortran. And by Fortran I mean Fortran IV. Have you tried to understand an algorithm implemented in Fortran IV? You would think, flowchart is a better representation, too, but it's actually wrong -- a better representation would be pseudocode. Procedural languages such as C and Pascal, and later object-oriented languages made pseudocode unnecessary.
7. There are really a lot of things that no one cares about, and even less so wants to see in a diagram form. Imagine a large ractangle labeled "libc", with a tree growing out of it with include files, groups of functions, functions and arguments attached to them. Have you seen it when studying C and libc? Do you know why you didn't? That's right, because it would be a confusing mess, distracting from both syntax and functionality, emphasizing superficial over essential. Your project does not need it any more than libc does.
8. Use simple tools that allow you to concentrate on readability, not completeness or compliance with a standard that makes you pretend that your diagram is formal and not informal part of documentation. XFig, Inksc
Here is an illustration of what I meant in my earlier comment. Instead of having a law that specifies precisely what punishment corresponds to a common and unremarkable crime we have on one hand ridiculous pileup of multiple charges for the same actions, and on the other hand, without any doubt, attorney claiming that it's all total bullshit, parole slashing prison terms to nearly nothing, etc. Let the shouting match begin, and expect a completely random result that has nothing to do with severity of the crime, deterrence, common sense and least of all -- justice.