Or, in other words, the concepts are simple to understand - a link just points a finger from here to some other spot somewhere in ordinary linear documents, which we all are used to create, read and manipulate.
But simple of tools can lead to a verbose and inefficient product. And that is what the web is. It's ridiculously verbose. There's a ton of information out there, but it's horribly unorganized. As a consumer of information, there's still a lot that I can't find easily on the web when I look for it; and there's ten times more information out there that would interest me, but that I didn't even think to look for.
Technology has a tremendous potential to revolutionize the nature of communication, and it has done so to a point. It's made speech more available. It's allowed people around the world to communicate where they couldn't before. But it hasn't changed the face of speech yet. Our language is still linear. Our non-linear thoughts are still forced to be expressed linearly. And guess what, a lot of data gets lost in that translation. And it doesn't have to be that way.
The problem is that we're wrapping new technology around a culture instead of building a new culture around technology.
What I admire about the developers of Xanadu is that they built new technology without waiting for people to catch up to them. If you examine the people behind any great advancement in art or science, this is a common habit among all of them. They are comfortable with the fact that culture just might get it someday.
The web is not good enough. The web is nowhere near good enough. The web is based on a very weak hypertext system: HTML. As far as hypertext systems go, HTML it is a quick and dirty solution to a much more complex problem. Beyond that, we now have XML, which is an even quicker and dirtier solution to the same complex problem.
The problem I'm talking about is symbolically linking context. It's very hard to do this with strings because strings are linear and context is not. For instance, in HTML, if I wanted to link you to an article on Wittgenstein, I write an A HREF tag around some text. Physically, that tag and that text are part of one big symbol that is parsed in to smaller symbols: a string parsed into substrings, and some of those substrings (when enclosed in < >) just so happen to be a link to some other big string of text.
But that's a horrible solution for several reasons. Firstly, I can only link one thing at a time. If I had a phrase "you should read these books on Wittgenstein" and I wanted to link the phrase "books on Wittgenstein" to several pieces of information on each book, the word "books" to information on books in general, and "Wittgenstein" to information about Wittgenstein, I can't do that. Why is that? Because there's no physical separation of form and function. Content and context exist in the same stream, and that's just asking for trouble.
Secondly, HTML is linear. Personally, I believe that the heart of this problem lies in the misapplication of the string. Fundamentally, what is a string? It's a linked list of characters. It's linear. This works very well for written and spoken language because they are both a linear stream of symbols. However, thought is not linear; context is not linear; and most importantly, comprehension is not linear. Those things are all non-linear. Why? Because the brain is non-linear.
This is the virtue of real hypertext. Hypertext seeks to address this issue. Hypertext addresses the non-linearity of ideas by expanding speech and literature into a multi-dimensional space. But HTML is to restrictive to really accommodate this. Sometimes that non-linearity expands into two dimensions, sometimes it expands into five. But HTML seeks to collapse it into a two-dimensional map always. Of course, you can have maps to other maps ("animal" to "mammal" to "dolphin"), but this design is inefficient. Furthermore, the links have limited cardinality ("there is no native support for two-way references or many-to-many links"). These are all significant burdens to the structure of the web.
I would suggest that we are not where we need to be and that HTML is only the beginning of real hypertextual technology. I was unfamiliar with the Xanadu project, but I personally find it very refreshing and relevant that this article was posted. I think many of the ideas are still capable of being implemented in new hypertext systems.
Most good IDE's already support autoformatting a document to fit the indenting and bracketing to the user. I don't see how putting formatting as a core part of the language will really help the language at all.
Ever program in Python?
of course it's possible, and some would say it already exists with languages like Lisp. But it wouldn't look anything like the code example provided. Why would anyone want to program in XML. IMHO, XML syntax is not appropriate for a programming language, it's appropriate for data representation.
It's like having a whole language made completely of nouns and adjectives. It's incomplete if you're trying to do anything beyond writing a grocery list. Great languages require nouns and verbs and descriptors. XML-type languages aren't adequate for something like this.
Correction. The last paragraph was meant to read:...but those aren't the jobs that people are after (here or there). Those >aren't< the firms that take care of their employees...
It's getting more and more competitive, though. For every 1 tech job in India, there are usually over 500 candidates. Firms in India can afford to be picky.
If it were just about throwing people in front of computers, then the quality of Indian software engineers would be lacking. But evidence shows the opposite. In 2003, 1671 American firms applied to the Carnegie-Mellon Software Engineering Institute for Level 5 CMM (Capability Maturity Model) certification. This is the Holy Grail of software quality certifications. Now compare those 1681 US applications with the mere 238 Indian firms that applied. Yet, out of the 78 certifications that were actually granted, 50 of the certifications went to Indian firms.
Indian firms are becoming serious players in the field of software engineering. It's not just about cheap labour. Sure, you may have some mindless codemonkey positions available like we have here in the states, but those aren't the jobs that people are after (here or there). Those are the firms that take care of their employees. Have you seen the office parks in Bangalore? Electronic City looks like it was airlifted straight out of our mid-1990s Silicon Valley. India's tech economy is *growing* while ours is drifting along at best. People may be making 20k a year now (which translates to 80k when you account for the much lower cost of living), but salaries are steadily increasing, the social and political situation is slowly improving, and soon there will be fewer reasons to move here. After all, how many programmers from Singapore or Japan have you seen immigrating to the states lately?
In general, tech jobs are ridiculously competitive in India. I couldn't imagine they would hire any programmers that didn't have at least a bachelor's degree. They have 1.04 billion people to pick from over there, so even the entry-level stuff requires an impressive resume.
Gambling revenue, in this case, would not be going to schools as the revenue is not within states jurisdiction. To my knowledge, online gambling sites are illegal to be hosted in the states. So the money is going directly into the pockets of some guy with a Carribean bank account.
I could see the advantage of integrating the decompression and parsing layers. Using simple Huffman coding, a tag like <THISISMYVERBOSETAG> would get assigned a binary symbol rather than an ascii substring.
Then, the XML parser simply can pre-search the *dictionary* for symbols that start with < and end with > and flags those symbols as tags explicitly. Then the parser can hunt through the compressed XML body to find those symbols directly. It makes a lot more sense than scanning through an ASCII file looking for > and <.
I had the chance to look at the HomePod last night at a friend's place. The device borrows from the iPod aesthetic rather blatantly but the construction appears to be lackluster.
On boot-up, the device made quite a few random clicking sounds which reminded me of a Geiger counter at Chernobyl. I'm not sure if this was an I/O problem with the audio circuitry or if this was supposed to happen. Once the device did in fact boot, we were able to play FM radio ok, but we had quite a bit of trouble configuring it to receive Internet Radio stations. The manufacturer's claims are a little misleading in that the device itself does not actually receive and interpret Internet Radio streams directly... but rather talks to an instance of a Java-based server from a PC on the network. I would imagine this server receives commands from the device, finds the stream, decompresses the streamed content, and moves it across the wireless network as PCM. I was a little disappointed by this topology because I expected this device to function independently. What we're left with is a glorified 802.11 transponder hooked up to a cheap sound card. It also boasts another would-be nifty feature which allows the playback of MP3 files from an attached USB hard drive, though we couldn't get that to work either.
The device has a very basic web administration console which can be accessed via the IP address, allowing one to change TCP/IP settings and FM presets, etc. We were also able to ssh into the device, apparently giving us root priveledges on the device. Hopefully, this will be locked up on the commercial version as the factory configuration might be serve up a very large backdoor to your wifi network.
In short, great idea but poor execution thus far. It has a good deal of potential if the bugs get worked out by shelf time.
Slashdot Mirror
So... fix it. It's wikipedia!
Or, in other words, the concepts are simple to understand - a link just points a finger from here to some other spot somewhere in ordinary linear documents, which we all are used to create, read and manipulate.
But simple of tools can lead to a verbose and inefficient product. And that is what the web is. It's ridiculously verbose. There's a ton of information out there, but it's horribly unorganized. As a consumer of information, there's still a lot that I can't find easily on the web when I look for it; and there's ten times more information out there that would interest me, but that I didn't even think to look for.
Technology has a tremendous potential to revolutionize the nature of communication, and it has done so to a point. It's made speech more available. It's allowed people around the world to communicate where they couldn't before. But it hasn't changed the face of speech yet. Our language is still linear. Our non-linear thoughts are still forced to be expressed linearly. And guess what, a lot of data gets lost in that translation. And it doesn't have to be that way.
The problem is that we're wrapping new technology around a culture instead of building a new culture around technology.
What I admire about the developers of Xanadu is that they built new technology without waiting for people to catch up to them. If you examine the people behind any great advancement in art or science, this is a common habit among all of them. They are comfortable with the fact that culture just might get it someday.
The web is not good enough. The web is nowhere near good enough. The web is based on a very weak hypertext system: HTML. As far as hypertext systems go, HTML it is a quick and dirty solution to a much more complex problem. Beyond that, we now have XML, which is an even quicker and dirtier solution to the same complex problem.
The problem I'm talking about is symbolically linking context. It's very hard to do this with strings because strings are linear and context is not. For instance, in HTML, if I wanted to link you to an article on Wittgenstein, I write an A HREF tag around some text. Physically, that tag and that text are part of one big symbol that is parsed in to smaller symbols: a string parsed into substrings, and some of those substrings (when enclosed in < >) just so happen to be a link to some other big string of text.
But that's a horrible solution for several reasons. Firstly, I can only link one thing at a time. If I had a phrase "you should read these books on Wittgenstein" and I wanted to link the phrase "books on Wittgenstein" to several pieces of information on each book, the word "books" to information on books in general, and "Wittgenstein" to information about Wittgenstein, I can't do that. Why is that? Because there's no physical separation of form and function. Content and context exist in the same stream, and that's just asking for trouble.
Secondly, HTML is linear. Personally, I believe that the heart of this problem lies in the misapplication of the string. Fundamentally, what is a string? It's a linked list of characters. It's linear. This works very well for written and spoken language because they are both a linear stream of symbols. However, thought is not linear; context is not linear; and most importantly, comprehension is not linear. Those things are all non-linear. Why? Because the brain is non-linear.
This is the virtue of real hypertext. Hypertext seeks to address this issue. Hypertext addresses the non-linearity of ideas by expanding speech and literature into a multi-dimensional space. But HTML is to restrictive to really accommodate this. Sometimes that non-linearity expands into two dimensions, sometimes it expands into five. But HTML seeks to collapse it into a two-dimensional map always. Of course, you can have maps to other maps ("animal" to "mammal" to "dolphin"), but this design is inefficient. Furthermore, the links have limited cardinality ("there is no native support for two-way references or many-to-many links"). These are all significant burdens to the structure of the web.
I would suggest that we are not where we need to be and that HTML is only the beginning of real hypertextual technology. I was unfamiliar with the Xanadu project, but I personally find it very refreshing and relevant that this article was posted. I think many of the ideas are still capable of being implemented in new hypertext systems.
Most good IDE's already support autoformatting a document to fit the indenting and bracketing to the user. I don't see how putting formatting as a core part of the language will really help the language at all. Ever program in Python?
of course it's possible, and some would say it already exists with languages like Lisp. But it wouldn't look anything like the code example provided. Why would anyone want to program in XML. IMHO, XML syntax is not appropriate for a programming language, it's appropriate for data representation. It's like having a whole language made completely of nouns and adjectives. It's incomplete if you're trying to do anything beyond writing a grocery list. Great languages require nouns and verbs and descriptors. XML-type languages aren't adequate for something like this.
Correction. The last paragraph was meant to read: ...but those aren't the jobs that people are after (here or there). Those >aren't< the firms that take care of their employees...
It's getting more and more competitive, though. For every 1 tech job in India, there are usually over 500 candidates. Firms in India can afford to be picky.
If it were just about throwing people in front of computers, then the quality of Indian software engineers would be lacking. But evidence shows the opposite. In 2003, 1671 American firms applied to the Carnegie-Mellon Software Engineering Institute for Level 5 CMM (Capability Maturity Model) certification. This is the Holy Grail of software quality certifications. Now compare those 1681 US applications with the mere 238 Indian firms that applied. Yet, out of the 78 certifications that were actually granted, 50 of the certifications went to Indian firms.
Indian firms are becoming serious players in the field of software engineering. It's not just about cheap labour. Sure, you may have some mindless codemonkey positions available like we have here in the states, but those aren't the jobs that people are after (here or there). Those are the firms that take care of their employees. Have you seen the office parks in Bangalore? Electronic City looks like it was airlifted straight out of our mid-1990s Silicon Valley. India's tech economy is *growing* while ours is drifting along at best. People may be making 20k a year now (which translates to 80k when you account for the much lower cost of living), but salaries are steadily increasing, the social and political situation is slowly improving, and soon there will be fewer reasons to move here. After all, how many programmers from Singapore or Japan have you seen immigrating to the states lately?
In general, tech jobs are ridiculously competitive in India. I couldn't imagine they would hire any programmers that didn't have at least a bachelor's degree. They have 1.04 billion people to pick from over there, so even the entry-level stuff requires an impressive resume.
Gambling revenue, in this case, would not be going to schools as the revenue is not within states jurisdiction. To my knowledge, online gambling sites are illegal to be hosted in the states. So the money is going directly into the pockets of some guy with a Carribean bank account.
That's assuming that unsliced bread is free, which it probably isn't.
I could see the advantage of integrating the decompression and parsing layers. Using simple Huffman coding, a tag like <THISISMYVERBOSETAG> would get assigned a binary symbol rather than an ascii substring.
Then, the XML parser simply can pre-search the *dictionary* for symbols that start with < and end with > and flags those symbols as tags explicitly. Then the parser can hunt through the compressed XML body to find those symbols directly. It makes a lot more sense than scanning through an ASCII file looking for > and <.
I had the chance to look at the HomePod last night at a friend's place. The device borrows from the iPod aesthetic rather blatantly but the construction appears to be lackluster. On boot-up, the device made quite a few random clicking sounds which reminded me of a Geiger counter at Chernobyl. I'm not sure if this was an I/O problem with the audio circuitry or if this was supposed to happen. Once the device did in fact boot, we were able to play FM radio ok, but we had quite a bit of trouble configuring it to receive Internet Radio stations. The manufacturer's claims are a little misleading in that the device itself does not actually receive and interpret Internet Radio streams directly... but rather talks to an instance of a Java-based server from a PC on the network. I would imagine this server receives commands from the device, finds the stream, decompresses the streamed content, and moves it across the wireless network as PCM. I was a little disappointed by this topology because I expected this device to function independently. What we're left with is a glorified 802.11 transponder hooked up to a cheap sound card. It also boasts another would-be nifty feature which allows the playback of MP3 files from an attached USB hard drive, though we couldn't get that to work either. The device has a very basic web administration console which can be accessed via the IP address, allowing one to change TCP/IP settings and FM presets, etc. We were also able to ssh into the device, apparently giving us root priveledges on the device. Hopefully, this will be locked up on the commercial version as the factory configuration might be serve up a very large backdoor to your wifi network. In short, great idea but poor execution thus far. It has a good deal of potential if the bugs get worked out by shelf time.