I was about to suggest that LaTeX is much harder to parse, but given the length of time it takes to display some of the web pages out there, I don't know.
Parsing LaTeX is easier than parsing HTML; LaTeX keywords are escaped with a backslash, and keywords end with a space, or with bracket pairs to define parameters. HTML requires parsing of bra/ket (less than/greater than) pairs, and the attribute values within the first pair. Not much more difficult, but harder than parsing LaTeX.
LaTeX output looks orders of magnitude better than HTML output. It's designed to be rendered on very high DPI printed page output - the algorithm takes a lot of time with kerning, line breaking, placing of floats/diagrams, and the like. By comparison, HTML just spews text on the page. For web pages, this is a perfectly functional alternative, but make no mistake - (La)TeX does a lot more than HTML ever does.
There's the added bonus that TeX works. For years, Donald Knuth was offering monetary rewards for bugs. He recently declared that he didn't think there were any more bugs in TeX and was going to halt development to maintain compatibility.
`Monetary reward' makes it sound like it's a lot more than it really is - you get a cheque for $2.56 if you find a bug in his textbooks, or $3.14 if you find a bug in TeX. It's mostly a kudos factor of having a cheque from the man.
The last reported bug in TeX was about 10 years ago (IIRC), and Knuth has declared that at the time of his death, any bug still remaining will be declared an official feature.
It appears to me that the problem with the US voting system is much deeper seated that just the plurality voting mechanism; the whole electoral college system is a bit of a mess (from a game theory/mathematics point of view).
Consider a US Federal Election between two candidates X and Y. Consider as a subset of the entire result the electoral results in California (53 college votes up for grabs, or ~10% of the college total).
In the election, X gets 51% of the vote, and Y gets 49%. This would suggest that the college return 23 votes for X, and 22 for Y. Yet the Californian electoral college returns all 53 college votes for candidate X. A majority of 1 vote in 1 state could return a 5% swing in the final electoral college count.
As I understand it, there are only a few states that allow their college votes to be split in any way whatsoever, and usually only as a 60/40 split.
This problem gets worse when you enter a `minor' candidate Z into the picture; the plurality voting mechanism exacerbates the problem with the colleges (If Z polls 5% in California, why shouldn't s/he get 2-3 college votes?), but it is by no means the only problem. Replacing plurality with any other voting system, but maintaining the colleges will leave you with the same old mess, just a slightly different shade of brown.
As a side note - don't knock a 2 party duopoly. As largely unrepresentative and stoic as it is, it does yield stability. Check out the Italian or Japanese parliament (and to a lesser extent, the Israeli parliament, and even the Australian Senate) if you want to see the effect of a large number of minority parties on the stablity of a democracy. Stability is often worth its weight in representative democracy.
Just my A$0.02 (approx US$0.01 at the current exchange rate...)
It strikes me that in this frenzy to get platform independent binaries, the obvious point of convergence and compatibility is getting lost.
Java has its version of bytecode, C# has its own incompatible version, and now Internet C++ has its version. Each bytecode is tightly coupled to a specific language (or small subset of languages), and ne'er the `twain shall meet.
Why not develop the bytecode specification as the point of compatibility? A feature rich "meta-assembly" with all the basic operations, plus a widget toolkit interface, network interface, etc. Provide a specification to the API in a generic, language NON-specific form and provide a reference implementation in a language of choice (Java, C++, C#, Prolog, whatever). Write a compiler backend for gcc and you get a shirtload of language interfaces in one hit.
Then developers can choose they language they want to develop in, and compile to a binary object format that will run anywhere, and be binary compatible with objects written in any other language!
Provide a JIT compiler to convert bytecode to system code, and you get a system native binary, using system native widgets (finally ending the GTK/QT/Motif/Xt wars).
This would make bytecode a sort of half way house between Java et al (One language, one machine, tell me the path to the binary), and CORBA (Many languages, any machine, I'll find the path to the binary).
Granted, Java (and C#) has given the world a new language which does a better job of object orientation than C++, but they have left the world with yet another language dependency, and a shirtload of code that has to be rewritten in a new language to support the new binary format.
By your reasoning, RedHat shouldn't have ANY revenue - ever. But strangely, they do - by selling related products and services, which are just as valuable as the software itself.
I don't know the specific details of the NCSU deal, but at a rough guess, how about:
A support contract for the IT staff
A great wad of user manuals
A shirtload of boxed sets to give to students
A discount (or free) support deal for students
All of these cost money, and are part of RedHat's normal revenue stream. Easy to make up a $350,000 donation out of these components (and I'm sure there could be others).
Just `cause RedHat does something generous and gets some publicity doesn't mean its propaganda...
If it keeps catching on, then don't you think that this will be heaven for spammers? Imagine, people using this during church and getting a message about buying holy books
Hey - don't joke. It's already happening here in Australia. I've received a number of pieces of spam from my mobile provider about competitions to win Olympic tickets; there has been serious discussion about using SMS sell "Team X just won the grand final" shirts minutes after the final siren. Take all the people using the mobile cell for the stadium as a mailing list, and boom - instant spam.
It doesn't help that Aussie mobile providers are doing the serious hard sell - one provider is offering all SMS messages for free for a few months, just to get people signed up and hooked...
Slashdot Mirror
I was about to suggest that LaTeX is much harder to parse, but given the length of time it takes to display some of the web pages out there, I don't know.
Parsing LaTeX is easier than parsing HTML; LaTeX keywords are escaped with a backslash, and keywords end with a space, or with bracket pairs to define parameters. HTML requires parsing of bra/ket (less than/greater than) pairs, and the attribute values within the first pair. Not much more difficult, but harder than parsing LaTeX.
LaTeX output looks orders of magnitude better than HTML output. It's designed to be rendered on very high DPI printed page output - the algorithm takes a lot of time with kerning, line breaking, placing of floats/diagrams, and the like. By comparison, HTML just spews text on the page. For web pages, this is a perfectly functional alternative, but make no mistake - (La)TeX does a lot more than HTML ever does.
There's the added bonus that TeX works. For years, Donald Knuth was offering monetary rewards for bugs. He recently declared that he didn't think there were any more bugs in TeX and was going to halt development to maintain compatibility.
`Monetary reward' makes it sound like it's a lot more than it really is - you get a cheque for $2.56 if you find a bug in his textbooks, or $3.14 if you find a bug in TeX. It's mostly a kudos factor of having a cheque from the man.
The last reported bug in TeX was about 10 years ago (IIRC), and Knuth has declared that at the time of his death, any bug still remaining will be declared an official feature.
Russ %-)
It appears to me that the problem with the US voting system is much deeper seated that just the plurality voting mechanism; the whole electoral college system is a bit of a mess (from a game theory/mathematics point of view).
Consider a US Federal Election between two candidates X and Y. Consider as a subset of the entire result the electoral results in California (53 college votes up for grabs, or ~10% of the college total).
In the election, X gets 51% of the vote, and Y gets 49%. This would suggest that the college return 23 votes for X, and 22 for Y. Yet the Californian electoral college returns all 53 college votes for candidate X. A majority of 1 vote in 1 state could return a 5% swing in the final electoral college count.
As I understand it, there are only a few states that allow their college votes to be split in any way whatsoever, and usually only as a 60/40 split.
This problem gets worse when you enter a `minor' candidate Z into the picture; the plurality voting mechanism exacerbates the problem with the colleges (If Z polls 5% in California, why shouldn't s/he get 2-3 college votes?), but it is by no means the only problem. Replacing plurality with any other voting system, but maintaining the colleges will leave you with the same old mess, just a slightly different shade of brown.
As a side note - don't knock a 2 party duopoly. As largely unrepresentative and stoic as it is, it does yield stability. Check out the Italian or Japanese parliament (and to a lesser extent, the Israeli parliament, and even the Australian Senate) if you want to see the effect of a large number of minority parties on the stablity of a democracy. Stability is often worth its weight in representative democracy.
Just my A$0.02 (approx US$0.01 at the current exchange rate...)
Russ Magee %-)
Java has its version of bytecode, C# has its own incompatible version, and now Internet C++ has its version. Each bytecode is tightly coupled to a specific language (or small subset of languages), and ne'er the `twain shall meet.
Why not develop the bytecode specification as the point of compatibility? A feature rich "meta-assembly" with all the basic operations, plus a widget toolkit interface, network interface, etc. Provide a specification to the API in a generic, language NON-specific form and provide a reference implementation in a language of choice (Java, C++, C#, Prolog, whatever). Write a compiler backend for gcc and you get a shirtload of language interfaces in one hit.
Then developers can choose they language they want to develop in, and compile to a binary object format that will run anywhere, and be binary compatible with objects written in any other language!
Provide a JIT compiler to convert bytecode to system code, and you get a system native binary, using system native widgets (finally ending the GTK/QT/Motif/Xt wars).
This would make bytecode a sort of half way house between Java et al (One language, one machine, tell me the path to the binary), and CORBA (Many languages, any machine, I'll find the path to the binary).
Granted, Java (and C#) has given the world a new language which does a better job of object orientation than C++, but they have left the world with yet another language dependency, and a shirtload of code that has to be rewritten in a new language to support the new binary format.
Am I missing some big point here?
Russ Magee
I don't know the specific details of the NCSU deal, but at a rough guess, how about:
A support contract for the IT staff
A great wad of user manuals
A shirtload of boxed sets to give to students
A discount (or free) support deal for students
All of these cost money, and are part of RedHat's normal revenue stream. Easy to make up a $350,000 donation out of these components (and I'm sure there could be others).
Just `cause RedHat does something generous and gets some publicity doesn't mean its propaganda...
Russ Magee
If it keeps catching on, then don't you think that this will be heaven for spammers? Imagine, people using this during church and getting a message about buying holy books
Hey - don't joke. It's already happening here in Australia. I've received a number of pieces of spam from my mobile provider about competitions to win Olympic tickets; there has been serious discussion about using SMS sell "Team X just won the grand final" shirts minutes after the final siren. Take all the people using the mobile cell for the stadium as a mailing list, and boom - instant spam.
It doesn't help that Aussie mobile providers are doing the serious hard sell - one provider is offering all SMS messages for free for a few months, just to get people signed up and hooked...