I'm not saying on-line dating sites can't pay off, but MATHEMATICALLY speaking, if you want to save time and hassle, old school brick and mortar dating agencies are the way to go.
Exactly! Brick and mortar anything pays off better - the local pub, library, book store, grocery checkout aisle, park, skating rink... in other words, all those things that people who "get a life" indulge in...
We don't need YAUDSBSWWTMAMBOOOPM (Yet Another Useless Dating Site by Someone Who Wants To Make A Million Bucks Off Of Other People's Misery).
Really, just admit that you don't know how to meet other people, and that you figure if you're running a dating site, you'll get to skim all the ads, etc., AND make money without having to really work. Its not going to happen.
riiiight.... and if my grandmother had wheels, I'd be able to drive her to work... if I could be bothered to dig her up.
Also, if it were "dropped from a million miles up" like the gp poster posited, it almost definitely wouldn't splat on anything - its much more likely to slingshot around and return to "outer space". We're not dealing with a 2-body problem here.
Grow up - none of these is an "original" format - they've been in use for decades, well before the xml crap. You might want to look at the various system delimited formats - oh, wait, that predates the Internet by several decades, so its not as "cool" as xml.
The right tool for the right job - and xml is rarely the right tool.
Case in point - the code I'm working on at work - totally unusable because of bad decisions - the use of xml, the stl, an in-memory tree that is really stupidly implemented, other badly designed classes, reference-counting for garbage collection, locking of the whole process instead of individual threads, etc., - none of which are necessary in what is supposed to be a high-performance server. Its like theyy were allergic to malloc / free and simple data structures...
If you know how many fields there are in each record, then why did you need a special record delimiter to begin with? Sounds like a design mistake, which isn't surprising since it was ad-hoc...
Wrong - the special null delimiter is needed only for variable-length (and zero-length) fields and records. For fixed-length fields and records, no delimiter is needed.
For example: First Name\0x00Last Name\0x00Age0x00\0x00
In the above example, Cowboyneal has no first name and no age.
What's so hard to understand about that?
For a fixed-length field?recordset, just include a header...
FirstName:10:LastName:10:Age:3\n
Joe_______Blow_______42\n
Mary______Doe_______24\n
__________Cowboyneal___\n
Both are human-readable, both are easy and intuitive to parse out, the second one is self-documenting and fully supports random access, etc (and neither one is new - the first is used on most *nixes, with either a : or | instead of a null, databases have been using the latter format for decades).
By contrast, xml is an abortion. Heck, I'll go further - xml is the ultimate triumph of navel-gazing over real-world experience.
It works with fields of any size and any content, unless the language you're using is retarded and has strings of 255 chars max length, or character sets of one byte per character. In c, you don't care - treat it all as data bytes.
It works with wide-character and unicode character sets, so again, no problems with more than 255 characters.
One field holds the parent node record id, or is blank if its a top-level node.
But if the field is blank, the delimiting nulls (as per your previous post) are adjacent and it becomes indistinguishable from a record delimiter.
You've just added an ambiguity! If it's that easy for you, the inventor of the schema, to screw it up, how the heck is any other random dumbass going to manage to deal with it?
Wrong - if you know how many fields there are in each record (that's what headers are for, right?), then two nulls side-by-side won't be mistaken for the two-null record delimiter...
Also, you can use an ascii 0x20 (a space) for a blank field... there's no problem with semantics there:-)
Third, you can always replace a blank (if you're being anal) with a "TOP_NODE" identifier
Fourth, if you're using a fixed-width field, the problem never occurs.
The earth gets about 10 to 100 tons of material from space every day - much of this is dust that remains suspended in the upper atmosphere for years before it finally drifts down to the surface.
"ASCII doesn't even support the letters needed by the majority of the world's language."
UTF does - so just use UTF - no big deal, and a lot easier to parse out than xml, which is butt-ugly to parse, terrible to index, doesn't support random access read/write, etc.
"And what if you are not dealing with a table with record and fields but with a tree?"
Trees and graphs are not a problem - just like they aren't in regular table design (though it IS ugly). One field holds the parent node record id, or is blank if its a top-level node. A second field can hold the node type. Extend your schema as required.
"That will work until you need to use non-ascii content, to include the delimiter in the data itself (so that you need an escaping mechanism), you want to represent hierarchical data, you want to be able to compose data from different sources without semantic collisions, and what not."
Using a single null (0x00) to delimit each field, and two nulls to delimit each record, is UTF-friendly. As for non-ascii contents, just encode them in base64 (which you would probably be doing anyway in a cdata section).
You can delimit your data with nulls, for example (1 null byte per field, 2 null bytes per record). Even javascript can parse that out, and its unicode-compatible.
Or you can use fixed-width fields and records, in which case reading a record is as simple as an lseek (header_size + record_len * (recno - 1)). Generating indexes on the data is also much quicker, as is editing the data. With a fixed-width field and record, there's no need to rewrite the rest of the file if your new value is not the same width as the old value.
Transforms? Again, a lot quicker, since its much quicker to read than an xml tree.
10 years later, xml still sucks in comparison. The attempts to "fix" the problems ("binary xml", anyone?) are jokes.
All the time. Its not that hard. Also, if you're worried about such things as quoting, etc., you can always use fixed-width fields - makes indexing, looking up, and modifying values REAL FAST. Compare that to the mess of xml.
If everyone would just use one of the already written XML producers or parsers (the big ones, the ones that work) life would be much easier around here from time to time.
If everyone would just went back to using simple delimited ascii text life would be much easier around here.
If I'm not mistaken according to Micro Soft's EULA you don't actually own the software they do.
Microsoft doesn't own a single piece of software on this computer, or my home box. If they want to start "attacking" my systems with worms, maybe I should disassemble one of them and "fix" it. I'm sure most of you can figure out what would be the best way to "repurpose" such a stupid idea.
If I'm not mistaken, Microsoft has stated that they don't want DRM either. It is forced on them by the music and movie industry -- "either DRM the shit out of everything and we will allow you to compete with Apple or no music for you!" is essentially what the industry told Microsoft.
You're mistaken. Originally (back before iTunes even existed) Microsoft was pushing DRM to the video industry as a way to securely digitally ship movies to theatres, so the MPAA was (and still is) their customer. You are just a consumer..
If the end-using customer is their first thought, then please explain DRM.
Simple - their customers are the studios, MPAA, RIAA, etc. They want to sell them the idea of using MicrosoftWindowsDRM on their products.
What - you thought you were Microsofts' customer? You're a consumer, not a customer. And you'll consume whatever they feed you, until you get sick of it and either die or switch.
When I read about it In Scientific American, the cost had ballooned to a half-billion (and the wiki article, which quotes an original budget of under $200 million, is wrong - it was originally supposed to be $100 million. They had agreed to pay $500 / line for the software (which was 5x the going rate for finished, debugged software) figuring that there was NO way it would go over-budget.
is that at it's heart, artificial intelligence is fake intelligence
Politicians are fake intelligence... which just goes to show that we need a real definition of artificial intelligence, as opposed to artificial sub-morons.
Also, IIRC, they had something like $60billion in cash on hand last time I paid attention;
You haven't been paying attention in quite a while - they have less than $22B. in cash, and even with offering only half-chas and half-stock,they've said they would probably borrow to finance the deal.
Slashdot Mirror
We don't need YAUDSBSWWTMAMBOOOPM (Yet Another Useless Dating Site by Someone Who Wants To Make A Million Bucks Off Of Other People's Misery).
Really, just admit that you don't know how to meet other people, and that you figure if you're running a dating site, you'll get to skim all the ads, etc., AND make money without having to really work. Its not going to happen.
riiiight .... and if my grandmother had wheels, I'd be able to drive her to work ... if I could be bothered to dig her up.
Also, if it were "dropped from a million miles up" like the gp poster posited, it almost definitely wouldn't splat on anything - its much more likely to slingshot around and return to "outer space". We're not dealing with a 2-body problem here.
Grow up - none of these is an "original" format - they've been in use for decades, well before the xml crap. You might want to look at the various system delimited formats - oh, wait, that predates the Internet by several decades, so its not as "cool" as xml.
The right tool for the right job - and xml is rarely the right tool.
Case in point - the code I'm working on at work - totally unusable because of bad decisions - the use of xml, the stl, an in-memory tree that is really stupidly implemented, other badly designed classes, reference-counting for garbage collection, locking of the whole process instead of individual threads, etc., - none of which are necessary in what is supposed to be a high-performance server. Its like theyy were allergic to malloc / free and simple data structures ...
After all, if your ISP is serving you ads you don't want, they shouldn't be charging you the bandwidth used ...
Wrong - the special null delimiter is needed only for variable-length (and zero-length) fields and records. For fixed-length fields and records, no delimiter is needed.
For example: First Name\0x00Last Name\0x00Age0x00\0x00
Joe\0x00Blow\0x0042\0x00\0x00
Mary\0x00Doe\0x0024\0x00\0x00
\0x00Cowboyneal\0x00\0x00\0x00
In the above example, Cowboyneal has no first name and no age.
What's so hard to understand about that? For a fixed-length field?recordset, just include a header ...
FirstName:10:LastName:10:Age:3\n
Joe_______Blow_______42\n
Mary______Doe_______24\n
__________Cowboyneal___\n
Both are human-readable, both are easy and intuitive to parse out, the second one is self-documenting and fully supports random access, etc (and neither one is new - the first is used on most *nixes, with either a : or | instead of a null, databases have been using the latter format for decades).
By contrast, xml is an abortion. Heck, I'll go further - xml is the ultimate triumph of navel-gazing over real-world experience.
It works with fields of any size and any content, unless the language you're using is retarded and has strings of 255 chars max length, or character sets of one byte per character. In c, you don't care - treat it all as data bytes.
It works with wide-character and unicode character sets, so again, no problems with more than 255 characters.
Wrong - if you know how many fields there are in each record (that's what headers are for, right?), then two nulls side-by-side won't be mistaken for the two-null record delimiter ...
Also, you can use an ascii 0x20 (a space) for a blank field ... there's no problem with semantics there :-)
Third, you can always replace a blank (if you're being anal) with a "TOP_NODE" identifier
Fourth, if you're using a fixed-width field, the problem never occurs.
Its a LOT simpler than xml.
"That being proposed as an alternative in the context of a XML sucks thread is... hmmm... sad."
Don't knock it if you haven't tried it.
Advantages:
Contrast this with xml:
"If you dropped a pop bottle onto Earth from a great height, say a million miles, it would splat (air resistance excluded) at about 25,000 MPH."
Nope. The bottle has so little mass in relation to its volume that even the "air" 50 miles up would start to slow it down. This is why, for example, no matter how high you jump out of a plane, you can't fall much faster than 125 mph unless you "streamline" yourself.
The earth gets about 10 to 100 tons of material from space every day - much of this is dust that remains suspended in the upper atmosphere for years before it finally drifts down to the surface.
"ASCII doesn't even support the letters needed by the majority of the world's language."
UTF does - so just use UTF - no big deal, and a lot easier to parse out than xml, which is butt-ugly to parse, terrible to index, doesn't support random access read/write, etc.
"And what if you are not dealing with a table with record and fields but with a tree?"
Trees and graphs are not a problem - just like they aren't in regular table design (though it IS ugly). One field holds the parent node record id, or is blank if its a top-level node. A second field can hold the node type. Extend your schema as required.
"That will work until you need to use non-ascii content, to include the delimiter in the data itself (so that you need an escaping mechanism), you want to represent hierarchical data, you want to be able to compose data from different sources without semantic collisions, and what not."
Using a single null (0x00) to delimit each field, and two nulls to delimit each record, is UTF-friendly. As for non-ascii contents, just encode them in base64 (which you would probably be doing anyway in a cdata section).
Plain ascii text != csv.
You can delimit your data with nulls, for example (1 null byte per field, 2 null bytes per record). Even javascript can parse that out, and its unicode-compatible.
Or you can use fixed-width fields and records, in which case reading a record is as simple as an lseek (header_size + record_len * (recno - 1)). Generating indexes on the data is also much quicker, as is editing the data. With a fixed-width field and record, there's no need to rewrite the rest of the file if your new value is not the same width as the old value.
Transforms? Again, a lot quicker, since its much quicker to read than an xml tree.
10 years later, xml still sucks in comparison. The attempts to "fix" the problems ("binary xml", anyone?) are jokes.
"Ever tried parsing CSV?"
All the time. Its not that hard. Also, if you're worried about such things as quoting, etc., you can always use fixed-width fields - makes indexing, looking up, and modifying values REAL FAST. Compare that to the mess of xml.
Microsoft doesn't own a single piece of software on this computer, or my home box. If they want to start "attacking" my systems with worms, maybe I should disassemble one of them and "fix" it. I'm sure most of you can figure out what would be the best way to "repurpose" such a stupid idea.
You sound bitter. Can't write assembler?
You're mistaken. Originally (back before iTunes even existed) Microsoft was pushing DRM to the video industry as a way to securely digitally ship movies to theatres, so the MPAA was (and still is) their customer. You are just a consumer..
Simple - their customers are the studios, MPAA, RIAA, etc. They want to sell them the idea of using MicrosoftWindowsDRM on their products.
What - you thought you were Microsofts' customer? You're a consumer, not a customer. And you'll consume whatever they feed you, until you get sick of it and either die or switch.
So what do you propose the author ofthis story register as?
When I read about it In Scientific American, the cost had ballooned to a half-billion (and the wiki article, which quotes an original budget of under $200 million, is wrong - it was originally supposed to be $100 million. They had agreed to pay $500 / line for the software (which was 5x the going rate for finished, debugged software) figuring that there was NO way it would go over-budget.
Politicians are fake intelligence ... which just goes to show that we need a real definition of artificial intelligence, as opposed to artificial sub-morons.
Before trying something as ambitious as routing airplanes, why not see if they can route luggage?
You haven't been paying attention in quite a while - they have less than $22B. in cash, and even with offering only half-chas and half-stock,they've said they would probably borrow to finance the deal.