Though I'd say you're far too nice regarding goal 7...
If I were designing a better XML, here are the things I'd try:
* Dump attributes. The semantic difference between text/data and attribute/metadata makes some sense in SGML, but is hopelessly bogus for XML. Make everything elements.
* Replace closing labeled tags with a generic "close-element" tag like </>. This should get you back the terseness you give up by making attributes into elements.
Also, one of the major ideas of XML is to separate code from data, as opposed to Lisp where code and data are the same thing. Similar syntax, different philosophy, I guess.
Early in the history of AI, there was a lot of argument about procedural versus declarative knowledge representation - whether it was better/more powerful to represent knowledge as code or data structures. The consensus they finally came to was that it really doesn't matter - any sufficiently complex declarative knowledge representation becomes something you can embed procedures in, and procedural systems need to structure their code (or else you can't reason about it) so much that it starts to look declarative.
The Lisp 'code is data' philosophy is just the acceptance of this consensus.
XML got one thing right over unadorned S-expressions - document packaging, specifically versioning and character-set labeling. XML inherited this from SGML, and it's one of the few things it took from there that was actually worth keeping.
For a good laugh, read the Origin and Goals section of the XML spec. Of the ten goals for XML listed there:
XML shall be straightforwardly usable over the Internet.
XML shall support a wide variety of applications.
XML shall be compatible with SGML.
It shall be easy to write programs which process XML documents.
The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
XML documents should be human-legible and reasonably clear.
The XML design should be prepared quickly.
The design of XML shall be formal and concise.
XML documents shall be easy to create.
Terseness in XML markup is of minimal importance.
I'd say two of them were met, but were bad ideas (SGML compatibility, terseness unimportant), and five of them were completely missed (ease of use, human legibility, quickly designed, formal and concise, ease of creation).
In 1866, the Supreme Court ruled that corporations have the same rights as living persons. They leaned on the Fourteenth Amendment, not the First, but if a corporation is a person, it has First Amendment rights, too.
I agree this sucks, but it's hard to do anything about a century-old precedent.
(the subject is flamebait and overstated, but it did get you to read this, didn't it?)
According to Peter Norvig and Greg Sullivan, most of the patterns in the Gang of Four book are there to show users of common OO languages the canonical ways of getting around design flaws in those languages.
Norvig says 16 of 24 patterns either vanish completely or are significantly easier to implement in a dynamic OO language like CLOS or Dylan; Sullivan implements a tiny OO language in Scheme and uses it to implement all 24 patterns, with similar results.
This particular alleged terrorist confessed/bragged about his activities to a documentary maker, and the tape has been shown on al-Jazeera. If he isn't guilty, he's gone out of his way to look guilty.
My battery is just over a year old, and I haven't noticed anything unusual since moving to 10.2.4. I'm pretty hard on my battery, too - never shut down except to reboot after upgrades, rarely take my battery below 50% charge.
Javascript is a tolerable language, and Javascript per se is not all that unportable. The problem is the API/DOM that connects Javascript to its browser environment - that's where the gratuitous incompatibilities gallop in.
I believe Moore's Law made the current explosion in scripting languages possible, by lowering the bar for scripting language implementors.
Take the original scripting language, Lisp. I'm serious - Lisp programs are safe (no naked pointers, no buffer overflows), variables are untyped, development is interactive, the first implementations were purely interpreted. Making a Lisp system perform acceptably was beyond all but a few wizards, who had to invent many of the tricks routinely used to speed up interpreters today.
Today's desktops are roughly a million times faster than the dinosaurs of the early 60's that Lisp was born on, and a thousand times faster than the Lisp machines of the early 80's that Common Lisp matured on. Today, naieve implementations of interpreted languages have acceptable performance on modern hardware, especially when handling web transactions where network latency gives you more time to compute.
Don't be taken in by Kasparov's noble words about "scientific" study of computer chess. There are two ways to think about a man vs. machine chess match:
A scientific test. Everybody's preparations would be done openly. There would be joint post-game analysis with an emphasis on whose strategy worked better.
A sporting test. Everybody's preparations would be done in secret, to hopefully surprise the opposition. Post-game analysis would be done seperately by both sides, with spin thrusters fully engaged.
Kasparov does competitive chess for a living - he can't approach these games in a scientific quest-for-knowledge mode. Note that he gets paid competition rates for these games.
What he clearly wants is for him to be able to treat the computer teams as full-out adversaries, but for them to cooperate with him and give away anything they discover about chess. That way, they can't become a threat to him or his sport.
... large screen owners must be compensating for something, don't you think?
As for the referenced article and the in-flight connectivity problems, from the picture I gather they were testing Windows laptops, and it has been my experience that Apple WiFi gear just plain Works Better. I was at a NASA conference in San Francisco in December. The hotel and a local networking firm brought WiFi up to our meeting rooms. The access points were Linksys, but only the Apple laptops connected up with no trouble - the Windows users had to try lots of different configurations and reboot a lot before any of them could connect. XP, NT, beginner, wizard, didn't matter.
I assmue you've noticed that the seats in ariplanes and the windows don't match up. That's because the spacing for the seats is variable, as is the placement of the first-class/cattle-car divider. If the seats each had a 10*baseT jack, all those wires would have to be moveable. WiFi just hurts a lot less as far as installation and maintenance goes.
If they released it, people in the open source community would get to see a big Quartz application, solving problems they are familiar with. If the code were unusually pretty or slick, it might encourage others to get to know Quartz better, and to write their applications in a way that could more easily take advantage of it when ported. They would also eventually get the bug-stomping benefits of lots of eyeballs caressing their code.
The only reason I can see for them not to release the code would be that it uses uncommonly good generic window system algorithms that they don't want copied by others.
I have a 500 MHz iBook, which can get warm if I use it on a surface with little air circulation (like on top of its carrying case on my lap), so I picked up a Cool Pad, which cured it completely, and is a neat swivel to boot.
A coworker of mine has a recent Dell laptop. I assume this thing is one of those "desktop replacement" atrocities, because it has two fans, each about an inch in diameter, firing out of the back of it. I've used them occasionally to warm my hands in cold meeting rooms. He only runs it on batteries long enough to find a wall outlet.
My iBook might have a fan - I wouldn't know, I've never heard it or felt any breeze from the vent holes near the screen hinge.
Maybe she had just switched from an x86 laptop...
on
Baked Apple
·
· Score: 4, Funny
... and thought it wasn't getting hot enough when it ran.
I knew Powerbooks were tough...
on
Baked Apple
·
· Score: 1
... but baking at 400 degrees for 20 minutes?
EEEEEK!
And I thought I abused my iBook by pushing it off my desk a few times (once open and running) - it looks a little scratched and the hinge mount on the screen is a little bent, but no damage.
because the O-rings in its solid-fuel boosters leaked
because the boosters are made in two pieces
because the boosters have to be transported by rail and barge
because the boosters are manufactured in Utah
because the money to run the Shuttle has to be sprinkled across as many Congressional districts as possible (see here and here, especially the list of subcontractors at the bottom of the second one).
Before Challenger, the Air Force was planning to have a Shuttle fleet of its own, operating out of Vandenberg AFB. The Air Force Shuttle's boosters were going to be made all in one piece, on site, and would have been stronger and lighter than the reusable Shuttle SRBs, allowing more payload to orbit. They wouldn't have been reusable, but I doubt they would have been a lot more expensive when you factor in the costs of recycling SRBs (recovery, transport to and from Utah and refurbishing).
As usual, when you show Congress an engineering versus safety decision, it will choose the option that spends the most money in the most districts.
I'm a contractor at NASA/Goddard. One of the areas I work in is taking remote sensed data from multiple sources and correlating it. Guess what: spatial correlation is one of the hard problems, because there are a lot of different coordinate systems in use - lat/long based on one of a bazillion different spherical/ellipsoidal models of the earth, UTM grids, weird polar-centered grids, you name it. Semantic Web labeling of the coordinate systems would help, but without deep semantic knowledge of how to meaningfully convert between the systems, you're still hosed.
Translation between two languages/systems is often straightforward. The probability of meaningful translation among N systems drops rapidly as N increases, though. The hype about the Semantic Web always ends up promising "and then we'll be able to make everything interoperate". It's the same as the early XML hype, and is bogus for the same reasons. Both of them say "all we have to do is label everything and then we can use it all", when getting agreement on the meaning of the labels is an unsolved problem.
I keep mentioning Cyc because they're one of the few groups that have been trying over a long period of time to build universal, interoperable ontologies. They've been at it now since 1984, and they haven't made a whole lot of progress because the problem is hard.
We're arguing past each other here. You think Semantic Web labeling will help a lot; I'm sceptical, based on my background in AI, among other things. We'll see which of us is right about ten years from now.
Go back and read the original article again. Look at the example "search" he claims Semantic Web labeling will enable:
the Semantic Web offers controlled access to American health care data, plus databases charting the location and status of rivers, underground water, forests and local vegetation, along with economic data on local industries and what they produce -- all marked up in special vocabularies.
The chances that the ontologies used to label the many different data sources he tosses off in that one sentence will be meaningfully compatible are near zero. People are having enough trouble inside any one of those fields defining XML sublanguages that let them communicate unambiguously among themselves, much less cross-discipline.
I repeat: I'll believe it when I hear that Cyc is being used as a web indexing tool.
At least, it's not coming anytime soon without a major breakthrough in real-world ontology construction.
The Semantic Web is getting a lot of the same hype as XML got a short while ago. Most of this hype comes from people who got their first introduction to structured information via XML and related markup languages. These people by and large don't realize that XML and friends are a syntax which does very little to solve the deep semantic problems. If two documents are both in XML, or both have Semantic Web ontology data, you may or may not be able to combine them menaingfully - they may be based on different DTDs/schemas/ontologies, and you're hosed.
Despite the word in its name, the "Semantic Web" brings nothing new to the table for solving these semantic problems. Real AI researchers started working on these issues shortly after the field was created, and there have been no major advances in the last twenty years or so.
Wake me when Cyc can understand any significant fraction of Semantic Web-labeled pages.
... that's for the machine at home, which is primarily used for AppleWorks/Quicken/web browsing/email.
Our home Mac history:
1994 - Quadra 605
System 7.1 - 8.1 1997 - UMAX C500
System 7.5 - 9 2001 - 466 MHz G3 tower
System 9, OS X to the present
And I expect to not need to upgrade the current machine for at least another year or two - OS X runs just fine on it with 384 MB. We tend to buy machines near the end of their production runs - they have a little less performance than the front of the line, but cost lots less.
Slashdot Mirror
Though I'd say you're far too nice regarding goal 7...
..
..
If I were designing a better XML, here are the things I'd try:
* Dump attributes. The semantic difference between text/data and attribute/metadata makes some sense in SGML, but is hopelessly bogus for XML. Make everything elements.
* Replace closing labeled tags with a generic "close-element" tag like </>. This should get you back the terseness you give up by making attributes into elements.
This would turn:
<foo bar="baz"><mumble>grumble</mumble></foo>.
into
<foo><bar>baz</><mumble>grumble</></>.
which is close enough for my taste to:
(foo (bar "baz") (mumble "grumble"))
Early in the history of AI, there was a lot of argument about procedural versus declarative knowledge representation - whether it was better/more powerful to represent knowledge as code or data structures. The consensus they finally came to was that it really doesn't matter - any sufficiently complex declarative knowledge representation becomes something you can embed procedures in, and procedural systems need to structure their code (or else you can't reason about it) so much that it starts to look declarative.
The Lisp 'code is data' philosophy is just the acceptance of this consensus.
XML got one thing right over unadorned S-expressions - document packaging, specifically versioning and character-set labeling. XML inherited this from SGML, and it's one of the few things it took from there that was actually worth keeping.
For a good laugh, read the Origin and Goals section of the XML spec. Of the ten goals for XML listed there:
XML shall be straightforwardly usable over the Internet.
XML shall support a wide variety of applications.
XML shall be compatible with SGML.
It shall be easy to write programs which process XML documents.
The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
XML documents should be human-legible and reasonably clear.
The XML design should be prepared quickly.
The design of XML shall be formal and concise.
XML documents shall be easy to create.
Terseness in XML markup is of minimal importance.
I'd say two of them were met, but were bad ideas (SGML compatibility, terseness unimportant), and five of them were completely missed (ease of use, human legibility, quickly designed, formal and concise, ease of creation).
Thirty per cent is a failing grade, folks...
this?
It helps to use a language that has number-to-english-cardinal built into it (hint: it's the ~R entries in the format string).
In 1866, the Supreme Court ruled that corporations have the same rights as living persons. They leaned on the Fourteenth Amendment, not the First, but if a corporation is a person, it has First Amendment rights, too.
I agree this sucks, but it's hard to do anything about a century-old precedent.
(the subject is flamebait and overstated, but it did get you to read this, didn't it?)
According to Peter Norvig and Greg Sullivan, most of the patterns in the Gang of Four book are there to show users of common OO languages the canonical ways of getting around design flaws in those languages.
Norvig says 16 of 24 patterns either vanish completely or are significantly easier to implement in a dynamic OO language like CLOS or Dylan; Sullivan implements a tiny OO language in Scheme and uses it to implement all 24 patterns, with similar results.
Go read the papers before modding me down, huh?
This particular alleged terrorist confessed/bragged about his activities to a documentary maker, and the tape has been shown on al-Jazeera. If he isn't guilty, he's gone out of his way to look guilty.
My battery is just over a year old, and I haven't noticed anything unusual since moving to 10.2.4. I'm pretty hard on my battery, too - never shut down except to reboot after upgrades, rarely take my battery below 50% charge.
Hope it doesn't happen to me...
Javascript is a tolerable language, and Javascript per se is not all that unportable. The problem is the API/DOM that connects Javascript to its browser environment - that's where the gratuitous incompatibilities gallop in.
Browser wars leave behind battlefields full of gratuitous incompatibilities. A browser war on Mac OS might drive people back to Internet Explorer.
Remember, Javascript is one of the craterfields left behind from the Netscape/Microsoft browser war.
I believe Moore's Law made the current explosion in scripting languages possible, by lowering the bar for scripting language implementors.
Take the original scripting language, Lisp. I'm serious - Lisp programs are safe (no naked pointers, no buffer overflows), variables are untyped, development is interactive, the first implementations were purely interpreted. Making a Lisp system perform acceptably was beyond all but a few wizards, who had to invent many of the tricks routinely used to speed up interpreters today.
Today's desktops are roughly a million times faster than the dinosaurs of the early 60's that Lisp was born on, and a thousand times faster than the Lisp machines of the early 80's that Common Lisp matured on. Today, naieve implementations of interpreted languages have acceptable performance on modern hardware, especially when handling web transactions where network latency gives you more time to compute.
A scientific test. Everybody's preparations would be done openly. There would be joint post-game analysis with an emphasis on whose strategy worked better.
A sporting test. Everybody's preparations would be done in secret, to hopefully surprise the opposition. Post-game analysis would be done seperately by both sides, with spin thrusters fully engaged.
Kasparov does competitive chess for a living - he can't approach these games in a scientific quest-for-knowledge mode. Note that he gets paid competition rates for these games.
What he clearly wants is for him to be able to treat the computer teams as full-out adversaries, but for them to cooperate with him and give away anything they discover about chess. That way, they can't become a threat to him or his sport.
... large screen owners must be compensating for something, don't you think?
As for the referenced article and the in-flight connectivity problems, from the picture I gather they were testing Windows laptops, and it has been my experience that Apple WiFi gear just plain Works Better. I was at a NASA conference in San Francisco in December. The hotel and a local networking firm brought WiFi up to our meeting rooms. The access points were Linksys, but only the Apple laptops connected up with no trouble - the Windows users had to try lots of different configurations and reboot a lot before any of them could connect. XP, NT, beginner, wizard, didn't matter.
I assmue you've noticed that the seats in ariplanes and the windows don't match up. That's because the spacing for the seats is variable, as is the placement of the first-class/cattle-car divider. If the seats each had a 10*baseT jack, all those wires would have to be moveable. WiFi just hurts a lot less as far as installation and maintenance goes.
If they released it, people in the open source community would get to see a big Quartz application, solving problems they are familiar with. If the code were unusually pretty or slick, it might encourage others to get to know Quartz better, and to write their applications in a way that could more easily take advantage of it when ported. They would also eventually get the bug-stomping benefits of lots of eyeballs caressing their code.
The only reason I can see for them not to release the code would be that it uses uncommonly good generic window system algorithms that they don't want copied by others.
Here. Previously mentioned on Slashdot here.
The memo may or may not be a fake, but many of the peformance issues mentioned in it are real.
I have a 500 MHz iBook, which can get warm if I use it on a surface with little air circulation (like on top of its carrying case on my lap), so I picked up a Cool Pad, which cured it completely, and is a neat swivel to boot.
A coworker of mine has a recent Dell laptop. I assume this thing is one of those "desktop replacement" atrocities, because it has two fans, each about an inch in diameter, firing out of the back of it. I've used them occasionally to warm my hands in cold meeting rooms. He only runs it on batteries long enough to find a wall outlet.
My iBook might have a fan - I wouldn't know, I've never heard it or felt any breeze from the vent holes near the screen hinge.
... and thought it wasn't getting hot enough when it ran.
... but baking at 400 degrees for 20 minutes?
EEEEEK!
And I thought I abused my iBook by pushing it off my desk a few times (once open and running) - it looks a little scratched and the hinge mount on the screen is a little bent, but no damage.
because the O-rings in its solid-fuel boosters leaked
because the boosters are made in two pieces
because the boosters have to be transported by rail and barge
because the boosters are manufactured in Utah
because the money to run the Shuttle has to be sprinkled across as many Congressional districts as possible (see here and here, especially the list of subcontractors at the bottom of the second one).
Before Challenger, the Air Force was planning to have a Shuttle fleet of its own, operating out of Vandenberg AFB. The Air Force Shuttle's boosters were going to be made all in one piece, on site, and would have been stronger and lighter than the reusable Shuttle SRBs, allowing more payload to orbit. They wouldn't have been reusable, but I doubt they would have been a lot more expensive when you factor in the costs of recycling SRBs (recovery, transport to and from Utah and refurbishing).
As usual, when you show Congress an engineering versus safety decision, it will choose the option that spends the most money in the most districts.
... the longest-used, most consistently enforced set of user interface guidelines in the industry for some ideas.
I'm a contractor at NASA/Goddard. One of the areas I work in is taking remote sensed data from multiple sources and correlating it. Guess what: spatial correlation is one of the hard problems, because there are a lot of different coordinate systems in use - lat/long based on one of a bazillion different spherical/ellipsoidal models of the earth, UTM grids, weird polar-centered grids, you name it. Semantic Web labeling of the coordinate systems would help, but without deep semantic knowledge of how to meaningfully convert between the systems, you're still hosed.
Translation between two languages/systems is often straightforward. The probability of meaningful translation among N systems drops rapidly as N increases, though. The hype about the Semantic Web always ends up promising "and then we'll be able to make everything interoperate". It's the same as the early XML hype, and is bogus for the same reasons. Both of them say "all we have to do is label everything and then we can use it all", when getting agreement on the meaning of the labels is an unsolved problem.
I keep mentioning Cyc because they're one of the few groups that have been trying over a long period of time to build universal, interoperable ontologies. They've been at it now since 1984, and they haven't made a whole lot of progress because the problem is hard.
We're arguing past each other here. You think Semantic Web labeling will help a lot; I'm sceptical, based on my background in AI, among other things. We'll see which of us is right about ten years from now.
The chances that the ontologies used to label the many different data sources he tosses off in that one sentence will be meaningfully compatible are near zero. People are having enough trouble inside any one of those fields defining XML sublanguages that let them communicate unambiguously among themselves, much less cross-discipline.
I repeat: I'll believe it when I hear that Cyc is being used as a web indexing tool.
At least, it's not coming anytime soon without a major breakthrough in real-world ontology construction.
The Semantic Web is getting a lot of the same hype as XML got a short while ago. Most of this hype comes from people who got their first introduction to structured information via XML and related markup languages. These people by and large don't realize that XML and friends are a syntax which does very little to solve the deep semantic problems. If two documents are both in XML, or both have Semantic Web ontology data, you may or may not be able to combine them menaingfully - they may be based on different DTDs/schemas/ontologies, and you're hosed.
Despite the word in its name, the "Semantic Web" brings nothing new to the table for solving these semantic problems. Real AI researchers started working on these issues shortly after the field was created, and there have been no major advances in the last twenty years or so.
Wake me when Cyc can understand any significant fraction of Semantic Web-labeled pages.
... that's for the machine at home, which is primarily used for AppleWorks/Quicken/web browsing/email.
Our home Mac history:
1994 - Quadra 605
System 7.1 - 8.1
1997 - UMAX C500
System 7.5 - 9
2001 - 466 MHz G3 tower
System 9, OS X to the present
And I expect to not need to upgrade the current machine for at least another year or two - OS X runs just fine on it with 384 MB. We tend to buy machines near the end of their production runs - they have a little less performance than the front of the line, but cost lots less.