By Roger F. Gay
Just read some material related to a 2011 book entitled, “The Believing Brain”, “synthesizing thirty years of research by psychologist, historian of science, and the world's best-known skeptic Michael Shermer.” Although I've never heard of him, Shermer's “theory of belief” rests on the insight that people develop response patterns, which can in any given circumstance turn out to be right or wrong.
The two key words are “patternicity” and “agenticity”. Shermer's “patternicity”, more specifically, refers to the tendency to find patterns where there are none. This seems to give away the author's purpose; to explain why some people believe things that he doesn't. “Agenticity” follows by imagining that causal agents exist to control what is perceived in the patterns; like governments for example. There are a lot of “conspiracy theorists” out there who believe that governments exist and that they have a lot of power, and that the exercise of that power actually has a significant impact via law, regulation, enforcement, and abuse. Evolutionary forces have given us all the tendency to hold such false beliefs, and therefore “science” should reign instead.
Perhaps a fan will add another marketing-driven copy-paste-modify review of his book somewhere, but this is not the purpose of my article. His thesis suggests a higher level of thought and behavior being subject to control by your “Inner Zombie”. So, I thought it might be time to post another comment on the topic. The background for my discussion here is that I'm an old guy. I'm pretty sure I've seen the Inner Zombie at work throughout my lifetime and even recognized it working in me.
Let me start with an effort to be less politically driven by categorizing with less prejudice. I will start with the premise that the theory that anyone can know everything about everything has been disproved. Waiting for answers from “science” (in quotes because I will be discussing the term) before proceeding on each course of action would have led to our extinction. I'm going to move along a different path (than Shermer's) from this reality. Making decisions with less than complete information is one of the highest behavioral skills humans have, and one that AI and science generally tend to struggle with. Cracking into its secrets could be profound.
If you look at the research on child development, which is the most solid and well-researched part of human development science, you will most definitely find innate behavior related to recognizing and classifying patterns. No one who's familiar with AI work would doubt that either. One of the familiar characteristics of intellectual development is generalization. Birds and airplanes fly. Parents point to them by pointing up. In the experience of a young child, they are the same thing (at least have the same name) until someone explains the difference.
It seems quite obvious that our innate ability to generalize is strongly related to our ability to think abstractly. What results from the ability to fly, for example, might be applied to anything that flies. (Go ahead. Take a chance.) Abstract symbols (like language) flow naturally from our lips while applying what we know or think we know about a class of things; knowledge we get from generalizing.
Our simple pattern matching and generalizing can be correct, like noticing that birds and airplanes both fly, or that parents can point upward and express fascination when referring to either one; while our generalizations may be flawed and conclusions that follow may be wrong.
It also seems rather obvious, to an old man at least, that we know the trick behind the absolutely superior human ability to make decisions with less than complete information. And this should surely be worth noting in the artificial intelligence community. I'm suggesting that actual real-world human-level “intuition” may be more easily achieved artificially than anyone who's thoughts on the topic that I've ever heard or read seems to think.
OK, ok. Let's be a little less optimistic since merely thinking an idea isn't implementing it. At least in theory, it seems we have a map. And perhaps the biggest leap of belief to accepting the map is that humans aren't advanced calculating machines that always get the answers right. They just usually draw conclusions sufficient for survival of the species, which is strongly related to individual survival. We don't need to be perfect and we're not.
Where we really need to start is by imagining a group of stereotypical Hollywood “Valley girls” parading through a mall and chatting. Many of the basic facts they rely on, that come directly from direct observation, may be objectively accurate. For most of us, their choice of focus, common frame of reference, and conclusions demonstrate the flexibility and adaptability resulting from our ability to generalize and abstract. Any conclusions they draw from abstract thinking might be wrong. In that respect, they're just like the rest of us.
I'm hoping that the “Valley girl” reference might have evoked a prejudice in you (yes you, the reader); a particular composite that might be useful in communicating my point – even though I have no idea how the IQ of girls from the San Fernando Valley compare with the general population. If we want to aim realistically at human-level behavior, then we have to accept that we're not going to get there by trying to create “perfect” machines that always get the answers right. The latter involves too much focus on a desirable result, great machines, and not enough on a process that's still doing a lot of things much better. Mixing the two can also make us think that humans are inherently flawed, and such an undesirable model that we'd like nothing more to do with them.
We are all scientists, even Valley girls. Let's now follow along as our group of stereotypical girls drive home. Let me further reveal the ending. They get home safe and sound. They're still the same people, yet no matter how flawed we imagine the conclusions they drew while chatting in the mall, they still did well enough with the driving task to get the job done. Why does this make them scientists? It does because, unlike any flights of fancy in their chat (including gossip about the other girls and boys), driving involves constant real-world objective feedback. This is what science is made of. They're engaging in the scientific process in its most primitive and natural form. With each action and reaction, their judgments are tested and they are aware of the results they yield. They have learned from the process.
I'm going to end this article, which has grown too long under the weight my informal blogging style at this point, with one simple reference. I don't know how much each of you will need to think about it, but feel reasonably certain (even though I don't know you so I'm working here with insufficient information) that you'll, to varying extent, understand my point. HAL 9000. (I'm guessing you know how it works, at least to the extent explained by the story.)
Sunday, May 12, 2013
Monday, February 18, 2013
Saturday, January 12, 2013
WebSockets with Apache Tomcat and HLL
I announced the HLL WebSocket Server Demonstration in September, 2011. Since then, it's been running full-time on an old Acer notebook that currently resides out in the hallway. (This time on Ubuntu Linux.)
The web page involved in the demonstration had been served from somewhere in California from a 24/7 hosting site, which I've recently decided I don't want to pay for anymore. So, I installed Tomcat 7 on the little Acer machine to serve the content I had remaining there, including the WebSocket demonstration web page. And there you have it. Tomcat is working with WebSockets all on the same machine. Just what everyone has been waiting and hoping for.
The irony is that HLL was designed to connect from anything to anything else, no matter where the various components are in the world. It works just as well if one machine is in Singapore and another in Stockholm. Of course, two components on the same machine are going to interact faster on average. But it really doesn't otherwise matter where the http server is or what brand of server it is. As it is, my HLL WebSocket server components are not installed under Tomcat, even though they're on the same machine. The demonstration provides a websocket connection between the client browser and the websocket server. So seriously, it doesn't matter where the http server is that provides the web page to begin with.
And of course, since it's all based on a real-live standard, any real WebSocket system can talk to any other real WebSocket system. So, if there are eventually some web app components using Apache technology, they can as easily communicate with HLL WebSocket connections as their own and vice versa. (I've also been considering support in HLL for the FIPA standard for message content. Who's with me? -high-five! ... along with other options.)
My heavy interest in WebSockets is directly related to HLL. WebSocket components can reside anywhere and talk with components anywhere else. They don't need to reside under an http server. I've been doing that type of communication for years between web app components. What I really needed was a standard approach supported by browsers. WebSockets Rock! And since my WebSocket server starts with a gateway process, I'd be just as happy using that to pass requests to Tomcat rather than the other way around. (Very fast gateway. You wouldn't notice the difference, especially on the same machine or even in the same LAN.) With HLL configuration, the whole idea is a piece of cake.
Nonetheless, I would like to make it easy for myself and other application developers (associated or willing to hire me, or fund me in some way) to use WebSockets in a very flexible way. I think they're great. One of those ways will be to install my WebSocket client (see note below) to be shared across all web applications, making it very simple to initiate a WebSocket connection from a servlet or other webapp component. I'll do that when I have time, which won't be this month, or sooner if someone steps up and offers the right price. :)
Note: We have to be careful about using the terms “client” and “server” when talking about WebSockets.
I assume it makes sense to people who've been through the same initial tutorials that I have. You've probably first learned that a browser initiates the connection pretty much like it does with http. The “server” responds and then you have a bidirectional connection for as long as you like.
But once you get past that, and very quickly indeed with any out-of-browser experience, and realize that there is no longer a master-slave relationship between the two ends of a WebSocket connection. A stand-alone “client” (if I can lean on that term at least once more) written in Java, for example, should contain the same technology as the “server” and thus can as easily act like one. You can have communication between two such “clients” passing information back and forth as needed.
The web page involved in the demonstration had been served from somewhere in California from a 24/7 hosting site, which I've recently decided I don't want to pay for anymore. So, I installed Tomcat 7 on the little Acer machine to serve the content I had remaining there, including the WebSocket demonstration web page. And there you have it. Tomcat is working with WebSockets all on the same machine. Just what everyone has been waiting and hoping for.
The irony is that HLL was designed to connect from anything to anything else, no matter where the various components are in the world. It works just as well if one machine is in Singapore and another in Stockholm. Of course, two components on the same machine are going to interact faster on average. But it really doesn't otherwise matter where the http server is or what brand of server it is. As it is, my HLL WebSocket server components are not installed under Tomcat, even though they're on the same machine. The demonstration provides a websocket connection between the client browser and the websocket server. So seriously, it doesn't matter where the http server is that provides the web page to begin with.
And of course, since it's all based on a real-live standard, any real WebSocket system can talk to any other real WebSocket system. So, if there are eventually some web app components using Apache technology, they can as easily communicate with HLL WebSocket connections as their own and vice versa. (I've also been considering support in HLL for the FIPA standard for message content. Who's with me? -high-five! ... along with other options.)
My heavy interest in WebSockets is directly related to HLL. WebSocket components can reside anywhere and talk with components anywhere else. They don't need to reside under an http server. I've been doing that type of communication for years between web app components. What I really needed was a standard approach supported by browsers. WebSockets Rock! And since my WebSocket server starts with a gateway process, I'd be just as happy using that to pass requests to Tomcat rather than the other way around. (Very fast gateway. You wouldn't notice the difference, especially on the same machine or even in the same LAN.) With HLL configuration, the whole idea is a piece of cake.
Nonetheless, I would like to make it easy for myself and other application developers (associated or willing to hire me, or fund me in some way) to use WebSockets in a very flexible way. I think they're great. One of those ways will be to install my WebSocket client (see note below) to be shared across all web applications, making it very simple to initiate a WebSocket connection from a servlet or other webapp component. I'll do that when I have time, which won't be this month, or sooner if someone steps up and offers the right price. :)
Note: We have to be careful about using the terms “client” and “server” when talking about WebSockets.
I assume it makes sense to people who've been through the same initial tutorials that I have. You've probably first learned that a browser initiates the connection pretty much like it does with http. The “server” responds and then you have a bidirectional connection for as long as you like.
But once you get past that, and very quickly indeed with any out-of-browser experience, and realize that there is no longer a master-slave relationship between the two ends of a WebSocket connection. A stand-alone “client” (if I can lean on that term at least once more) written in Java, for example, should contain the same technology as the “server” and thus can as easily act like one. You can have communication between two such “clients” passing information back and forth as needed.
Friday, September 21, 2012
Artificial Intelligence and Cognition: Defending my Optimism
“Engineers are naturally grumpy,” I once said. “If we ever start thinking those damned machines are something other than damned machines, we'll get packed away in white jackets.” Does our own natural attitude playing with our interpretation of progress have something to do with why artificial intelligence seems perpetually elusive?
I'm an optimist on developing artificial intelligence, but not very optimistic about convincing others that anything we do can be counted as much more than a trivial re visitation of things that have already been done. I think that engineering “grumpiness” is a key to understanding that no matter how far we get, accomplishing anything really interesting will still seem to be a long way off.
First let me say that I'm grumpy too. I can't help it. It's really more difficult for me to get a cuddly feeling from a robotic baby seal than it is for an old woman in Japan. I know too much about what's under the hood, or its skin? And my problem, which I'm certain is shared by other engineers and scientists, isn't just an emotional one.
My optimism also comes from knowing what's under the hood. My optimism regarding artificial (meaningful) self-awareness for example comes from the design of robots that learn and adapt. In a design by Peter Nordin (related article), robot software learns about the physical robot it runs by exercising its actuators and discovering their effects. The robot uses this self-knowledge to efficiently begin learning more complex behavior and ultimately about its environment and how to effectively interact with it. Instilled with “motives” their behavior becomes useful. It's also been demonstrated that robots can learn from direct human verbal interaction as a replacement for programming. (For example: English translation of Swedish documentary) Self-aware robots can distinguish between themselves and others and learn through interaction how they should treat others, a pathway to robot ethics.
“Humbug!” pronounced a world-famous engineering professor. (I paraphrase, perhaps very badly, to emphasize engineering grumpiness. I'll leave his real name out to allow my fictional character to more clearly illustrate the problem. It's “reality-based” we can say.) “In that last step,” a small demonstration of an additional idea at the end of a larger project to do other things, “rules were used. RULES! You can't get anywhere with rules. What they're trying to do is still decades away.”
It's not just world-famous engineering professors. As I've said, I suffer from the same affliction, as do many. I read (again) recently about a robot taking a self-awareness test that has often been given to animals. Place a robot in front of a mirror and see if it recognizes itself. “BAAAH HUMBUG!” I thought, seemingly without any ability whatsoever to restrain myself. That's just pattern recognition, no different than recognizing anything else. (The actual test involves changing something about the creatures appearance, typically by placing a mark on its body that it only sees in reflection, and seeing if the creature notices the change as being to itself, usually by pointing to it or touching it on its own body rather than in the reflection.)
Oh, but wait! Will this be the first time such an experiment has been conducted? If so, it would be a dandy wonderful experiment. It's the same one used by psychologists on living creatures. If successful, it in some way would prove that something interesting has happened (no matter how long we've understood that it could.). And in fact, I can actually use a phrase from the paragraph above, in which I was explaining my optimism, to explain the potential importance of this advance. Robots that recognize themselves can use that ability to “distinguish between themselves and others.”
But can we accept any of this as having anything really to do with self-awareness? Or are we (engineers at least) forever going to be the nay-sayers on account of the fact that we know the magic trick behind the “illusion”? I argue that we can be more positive and optimistic, and accepting of progress toward artificial intelligence and cognition by truly embracing our grumpiness. THEY'RE MACHINES!
Are we too often, unknowingly perhaps, making the mistake of thinking that developing artificial intelligence is synonymous with creating a synthetic human? Must machines hold the same mysteries of their inner-workings from us as those of living things in order for us to allow that we're well on the way to artificial intelligence? Must the goal always be hidden away in what we don't already know? (I could segue into the “singularity” here, but I won't … just mention it's where we expect to no longer understand what's going on.)
The trick, for us, I think, is to accept that machines are machines. They aren't something else. Let's extend the description of that latter experiment like this. A machine is let loose in a room with a mirror. It autonomously roams around the room and sees the mirror. Upon further investigation (still, autonomously), it sees its reflection and says, “Oh look, that's me.” That really is a pretty good trick for a machine. Does it wave its hand to confirm that it's looking at itself (perhaps only then learning from the image, how it looks)?
I don't have the sense that I've nailed this argument to the wall simply by posing the question in some context. As a proxy for things we already understand, let us reconsider that most humble of artificial intelligence techniques; rules. During commercialization of rule-based expert systems the 1980s, they were imagined as a step toward all kinds of software magic. These systems were after all, the product of artificial intelligence research. By the end of the 1980s, great expectations had crashed on the limits of those early rule-systems and it was thought that they should never be mentioned in this context again.
Now presume for a moment that I am a technically well-educated human being with experience. I understand how to use a rather wide range of techniques to solve problems, answer questions, and even to trigger decisions. Sometimes the use of one sophisticated technique, some kind of statistically analysis for example, is enough to accomplish what I need. Sometimes it takes a string of sophisticated operations to get where I need to go.
Many of the techniques I use can be performed with the help of a computer. In the example, statistics, there is much software available to support the task. Computers can already do this work much more rapidly and reliably than people. The trick here is to identify the right technique for each task, set things up, and run. I'm so smart. I'm human. I can do that and computers can't. Why? Because I have knowledge stored in my brain about what those techniques do. How do I apply that knowledge? Well … aahh … uhm … it's sort of like rules. Should I go ahead and develop a more autonomous level of useful computer processing, or just say naaaah, that would be so-o-o 1980s?
What if my more autonomous system could in fact perform this feat, but competes oddly against humans regarding which kinds of cases it understands how to handle? In other words, what if it has limitations, but they aren't the same as my limitations? In comparison, there are still some cases that I can handle better than the computer? Oh, yes, by the way: I have limitations. (Admit it, so do you.)
I'm an optimist on developing artificial intelligence, but not very optimistic about convincing others that anything we do can be counted as much more than a trivial re visitation of things that have already been done. I think that engineering “grumpiness” is a key to understanding that no matter how far we get, accomplishing anything really interesting will still seem to be a long way off.
First let me say that I'm grumpy too. I can't help it. It's really more difficult for me to get a cuddly feeling from a robotic baby seal than it is for an old woman in Japan. I know too much about what's under the hood, or its skin? And my problem, which I'm certain is shared by other engineers and scientists, isn't just an emotional one.
My optimism also comes from knowing what's under the hood. My optimism regarding artificial (meaningful) self-awareness for example comes from the design of robots that learn and adapt. In a design by Peter Nordin (related article), robot software learns about the physical robot it runs by exercising its actuators and discovering their effects. The robot uses this self-knowledge to efficiently begin learning more complex behavior and ultimately about its environment and how to effectively interact with it. Instilled with “motives” their behavior becomes useful. It's also been demonstrated that robots can learn from direct human verbal interaction as a replacement for programming. (For example: English translation of Swedish documentary) Self-aware robots can distinguish between themselves and others and learn through interaction how they should treat others, a pathway to robot ethics.
“Humbug!” pronounced a world-famous engineering professor. (I paraphrase, perhaps very badly, to emphasize engineering grumpiness. I'll leave his real name out to allow my fictional character to more clearly illustrate the problem. It's “reality-based” we can say.) “In that last step,” a small demonstration of an additional idea at the end of a larger project to do other things, “rules were used. RULES! You can't get anywhere with rules. What they're trying to do is still decades away.”
It's not just world-famous engineering professors. As I've said, I suffer from the same affliction, as do many. I read (again) recently about a robot taking a self-awareness test that has often been given to animals. Place a robot in front of a mirror and see if it recognizes itself. “BAAAH HUMBUG!” I thought, seemingly without any ability whatsoever to restrain myself. That's just pattern recognition, no different than recognizing anything else. (The actual test involves changing something about the creatures appearance, typically by placing a mark on its body that it only sees in reflection, and seeing if the creature notices the change as being to itself, usually by pointing to it or touching it on its own body rather than in the reflection.)
Oh, but wait! Will this be the first time such an experiment has been conducted? If so, it would be a dandy wonderful experiment. It's the same one used by psychologists on living creatures. If successful, it in some way would prove that something interesting has happened (no matter how long we've understood that it could.). And in fact, I can actually use a phrase from the paragraph above, in which I was explaining my optimism, to explain the potential importance of this advance. Robots that recognize themselves can use that ability to “distinguish between themselves and others.”
Are we too often, unknowingly perhaps, making the mistake of thinking that developing artificial intelligence is synonymous with creating a synthetic human? Must machines hold the same mysteries of their inner-workings from us as those of living things in order for us to allow that we're well on the way to artificial intelligence? Must the goal always be hidden away in what we don't already know? (I could segue into the “singularity” here, but I won't … just mention it's where we expect to no longer understand what's going on.)
The trick, for us, I think, is to accept that machines are machines. They aren't something else. Let's extend the description of that latter experiment like this. A machine is let loose in a room with a mirror. It autonomously roams around the room and sees the mirror. Upon further investigation (still, autonomously), it sees its reflection and says, “Oh look, that's me.” That really is a pretty good trick for a machine. Does it wave its hand to confirm that it's looking at itself (perhaps only then learning from the image, how it looks)?
I don't have the sense that I've nailed this argument to the wall simply by posing the question in some context. As a proxy for things we already understand, let us reconsider that most humble of artificial intelligence techniques; rules. During commercialization of rule-based expert systems the 1980s, they were imagined as a step toward all kinds of software magic. These systems were after all, the product of artificial intelligence research. By the end of the 1980s, great expectations had crashed on the limits of those early rule-systems and it was thought that they should never be mentioned in this context again.
Now presume for a moment that I am a technically well-educated human being with experience. I understand how to use a rather wide range of techniques to solve problems, answer questions, and even to trigger decisions. Sometimes the use of one sophisticated technique, some kind of statistically analysis for example, is enough to accomplish what I need. Sometimes it takes a string of sophisticated operations to get where I need to go.
Many of the techniques I use can be performed with the help of a computer. In the example, statistics, there is much software available to support the task. Computers can already do this work much more rapidly and reliably than people. The trick here is to identify the right technique for each task, set things up, and run. I'm so smart. I'm human. I can do that and computers can't. Why? Because I have knowledge stored in my brain about what those techniques do. How do I apply that knowledge? Well … aahh … uhm … it's sort of like rules. Should I go ahead and develop a more autonomous level of useful computer processing, or just say naaaah, that would be so-o-o 1980s?
What if my more autonomous system could in fact perform this feat, but competes oddly against humans regarding which kinds of cases it understands how to handle? In other words, what if it has limitations, but they aren't the same as my limitations? In comparison, there are still some cases that I can handle better than the computer? Oh, yes, by the way: I have limitations. (Admit it, so do you.)
Wednesday, April 4, 2012
High Level Logic and Constructal Law
I've just finished reading chapter 1 of Design in Nature, by Adrian Bejan and J. Peder Zane. (How the Constructal Law Governs Evolution in Biology, Physics, Technology, and Social Organizations) It has me wondering if constructal law will turn out to be the thing that will help me explain why HLL is a superior software framework.
Constructal law sees “design in nature” in terms evolving flow structures. From an author's description; “Constructal theory holds that flow architecture arises from the natural evolutionary tendency to generate greater flow access in time and in flow configurations that are free to morph.”
As mentioned, I've just finished chapter 1 of Design in Nature. I'm not ready yet to produce a proof, based on constructal law, that HLL is an advancement, and a fundamental advancement as I believe that it is. But even the concept, as explained, with examples, in the introductory chapter, raises some question whether it should be possible.
It's at least largely about flow. HLL is about logical flow, and designing (or evolving) “generic” (more accurately, “general” or “vastly reusable”) flows for high level logic. That might almost be said of any computer software; except for the “generic” or “general” or “vastly reusable” systematic flow of high level logic. Yes, as I said – not a proof yet.
I'm pushed along a bit by the experience of it all. It's not just about flow, but flow has always been on my mind as a critical aspect of HLL development; every piece of it; every aspect of it.
Recalling my early (mid 1980s) notes on HLL, I was very concerned about finding a more generic structure or container for passing data around. This is part of what, predictably, evolved in computer science while I was busy doing other things. Few understood my excitement over XML or my comments on the broad possible uses of RDF (having actually studied the standard rather than just fingering through an early example).
Fair enough (I hope you think), but the fact that these things evolved without HLL mean that other people were interested too. All I'm saying is that these developments were seriously stokin' my pipe for yet another set of dreams about how software development was and will evolve. One could produce “tree structures” for data that could morph. It seemed quite profound to me, not just convenient.
Because I'm not ready to prove anything yet and expect to discuss this further in the future, I'll be brief; taking you right to the latest. I did not feel that I could create the HLL system properly until WebSockets came along. Browsers are everywhere and that's why they should serve as the interface for applications. I need that symmetry of flow that WebSockets finally provide.
HLL isn't as restrictive as frameworks I've seen, not nearly as specialized. It should be free to express any application, rather easily.
What I've said at this point, is that I'm ready to see HLL in terms of flow architecture that arises from the natural evolutionary tendency to generate greater flow access in time and in flow configurations that are free to morph.
So, my pipe is back to producing dreams and we'll see what becomes of them.
.
Constructal law sees “design in nature” in terms evolving flow structures. From an author's description; “Constructal theory holds that flow architecture arises from the natural evolutionary tendency to generate greater flow access in time and in flow configurations that are free to morph.”
As mentioned, I've just finished chapter 1 of Design in Nature. I'm not ready yet to produce a proof, based on constructal law, that HLL is an advancement, and a fundamental advancement as I believe that it is. But even the concept, as explained, with examples, in the introductory chapter, raises some question whether it should be possible.
It's at least largely about flow. HLL is about logical flow, and designing (or evolving) “generic” (more accurately, “general” or “vastly reusable”) flows for high level logic. That might almost be said of any computer software; except for the “generic” or “general” or “vastly reusable” systematic flow of high level logic. Yes, as I said – not a proof yet.
I'm pushed along a bit by the experience of it all. It's not just about flow, but flow has always been on my mind as a critical aspect of HLL development; every piece of it; every aspect of it.
Recalling my early (mid 1980s) notes on HLL, I was very concerned about finding a more generic structure or container for passing data around. This is part of what, predictably, evolved in computer science while I was busy doing other things. Few understood my excitement over XML or my comments on the broad possible uses of RDF (having actually studied the standard rather than just fingering through an early example).
Fair enough (I hope you think), but the fact that these things evolved without HLL mean that other people were interested too. All I'm saying is that these developments were seriously stokin' my pipe for yet another set of dreams about how software development was and will evolve. One could produce “tree structures” for data that could morph. It seemed quite profound to me, not just convenient.
Because I'm not ready to prove anything yet and expect to discuss this further in the future, I'll be brief; taking you right to the latest. I did not feel that I could create the HLL system properly until WebSockets came along. Browsers are everywhere and that's why they should serve as the interface for applications. I need that symmetry of flow that WebSockets finally provide.
HLL isn't as restrictive as frameworks I've seen, not nearly as specialized. It should be free to express any application, rather easily.
What I've said at this point, is that I'm ready to see HLL in terms of flow architecture that arises from the natural evolutionary tendency to generate greater flow access in time and in flow configurations that are free to morph.
So, my pipe is back to producing dreams and we'll see what becomes of them.
.
Sunday, January 29, 2012
Wednesday, November 16, 2011
WebSocket Demonstration on Microsoft Internet Explorer
(January 12, 2013: Related article: WebSockets with Apache Tomcat and HLL)
The main article introducing the WebSocket server demonstration did not include much information about running it on Microsoft Internet Explorer. MSIE is a bit crippled until Google frame is installed, but here I've made the process as painless as possible, I think.
First, fire up MSIE and click on this link: Step 1. That should automatically call up a window asking if you want to install Google frame. Accept terms and conditions, etc. and wait until the process completes. You'll probably end up on a page suggesting an interesting vacation spot. You can close that page and return to this one.
Then, just go to the demo page: Step 2. The demonstration should work.
Leave a comment if you try it. I only have personal access to so many computers running MSIE. Would like to know if this works for everyone. If you comment on a problem, please note the version of MSIE and operating system.
(January 12, 2013: Related article: WebSockets with Apache Tomcat and HLL)
The main article introducing the WebSocket server demonstration did not include much information about running it on Microsoft Internet Explorer. MSIE is a bit crippled until Google frame is installed, but here I've made the process as painless as possible, I think.
First, fire up MSIE and click on this link: Step 1. That should automatically call up a window asking if you want to install Google frame. Accept terms and conditions, etc. and wait until the process completes. You'll probably end up on a page suggesting an interesting vacation spot. You can close that page and return to this one.
Then, just go to the demo page: Step 2. The demonstration should work.
Leave a comment if you try it. I only have personal access to so many computers running MSIE. Would like to know if this works for everyone. If you comment on a problem, please note the version of MSIE and operating system.
The HLL WebSocket demonstration running on MSIE.
.
(January 12, 2013: Related article: WebSockets with Apache Tomcat and HLL)
Saturday, November 12, 2011
Monday, September 26, 2011
Websocket Server Demonstration
(January 12, 2013: Related article: WebSockets with Apache Tomcat and HLL)
Subject: Pre-release demonstration for developers and others who are willing to install advanced browsers. When ready, this server will be available free to developers, with or without the HLL application software. The current version is set-up as a gateway and will include simple http processing at the time of release. (You won't have to have another server running to load web pages.)
Update (Oct. 2, 2011): Latest version of the websocket protocol (known as hybi-17) has been submitted as a proposed standard. (public notice) Technically, hybi-17 is expected to represent the first websocket standard, although there may still be revisions to the text of the written standard.
The HLL International Websocket Server is another fast, lightweight HLL component. (Running on localhost, response appears instantaneous, even with multiple “rapid-fire” requests.) I've been developing it independently so that it can act as a websocket server for all applications, whether they are HLL applications or not. HLL components will be added to make construction of any websocket application easier. HLL applications will use websockets seamlessly.
The current version is still under development. (I guess I'm just proving my sincerity with this demo.) The demonstration is like a lot of others found on the web. The web page is a bit more sophisticated. (You can download the code here, but note that it is unlikely to work unless installed on a server.) It's built for development and test, and modified as I go. But the underlying experience is that of a simple echo server. No complex applications have yet been built. I will however, hook up the robot simulation application when the server is fully integrated with HLL.
Since HLL supports distributed computing, using components anywhere in the world, the server responds to a new connection with a “Hello World!” message in Swedish: “Hallå Världen!” The default message to the echo server contains foreign characters that lie far outside the range of utf-8 (English). The server does not merely echo back the message. It processes the message first, without gumming it up; and returns its version of what it read.
The websocket standard is not yet final and I have only tested on a limited number of advanced browsers that support the most recent (i.e. proposed final) version of the websocket protocol. It works fine using Google Chrome dev-channel Chromium 14 and above and Firefox 7 and above. You should also expect to be unsuccessful when trying to connect through a proxy server. Most proxy servers have not been updated to handle websockets and will deliver an incorrect request header, causing the request to fail.
You will not get a response from the server when using browsers that do not support close to final (or final) versions of the actual websocket standard protocol or if your request runs through a proxy server (which modifies the request headers such that they are no longer compliant). The browser application will say "CONNECTION REQUESTED ...." after you click the "Open Connection" button. After a wait period it will tell you that the application is "DISCONNECTED".
Opera is currently supporting an older draft of the websocket standard that the HLL websocket server does not support. I'll hold out a bit longer to see if Opera announces an upgrade soon. Opera has done excellent work in support of the HTML5 standard generally and I want to support people who use it. The older draft version of the websocket standard will not be the final version however, so I keep expecting to hear about an Opera upgrade any time now.
I've gone so far as to set up the web page for MSIE. 8 or above to load Google's plug-in to support websockets.But I have not been willing so far to spend a few hours getting the common dhtml I've used to construct the web page working in MSIE. Maybe later. Microsoft reports that their browser will support websockets in version 10. (UPDATE: Demo on MSIE)
The demonstration server will be upgraded fairly frequently. I suspect there will be little chance that it will not be available for that reason when you try it, but it could happen. Important upgrades (such as the addition of http service) will be reported in this blog when they're ready. But because browser support for websockets is under development, I kind-of expect at least one major crash on at least one browser before it's all done. (Update: Not so much anymore. Things have been going smoothly.) I'm optimistic though. You should be too. If the web page loads a bit slowly, note that it isn't being delivered from the HLL WebSocket server.
You are invited to provide feedback. Simply add a comment under this article, or contact me by email.
If you have an appropriate web-browser, click here for the demonstration.
(January 12, 2013: Related article: WebSockets with Apache Tomcat and HLL)
Subject: Pre-release demonstration for developers and others who are willing to install advanced browsers. When ready, this server will be available free to developers, with or without the HLL application software. The current version is set-up as a gateway and will include simple http processing at the time of release. (You won't have to have another server running to load web pages.)
Update (Oct. 2, 2011): Latest version of the websocket protocol (known as hybi-17) has been submitted as a proposed standard. (public notice) Technically, hybi-17 is expected to represent the first websocket standard, although there may still be revisions to the text of the written standard.
The HLL International Websocket Server is another fast, lightweight HLL component. (Running on localhost, response appears instantaneous, even with multiple “rapid-fire” requests.) I've been developing it independently so that it can act as a websocket server for all applications, whether they are HLL applications or not. HLL components will be added to make construction of any websocket application easier. HLL applications will use websockets seamlessly.
The current version is still under development. (I guess I'm just proving my sincerity with this demo.) The demonstration is like a lot of others found on the web. The web page is a bit more sophisticated. (You can download the code here, but note that it is unlikely to work unless installed on a server.) It's built for development and test, and modified as I go. But the underlying experience is that of a simple echo server. No complex applications have yet been built. I will however, hook up the robot simulation application when the server is fully integrated with HLL.
Since HLL supports distributed computing, using components anywhere in the world, the server responds to a new connection with a “Hello World!” message in Swedish: “Hallå Världen!” The default message to the echo server contains foreign characters that lie far outside the range of utf-8 (English). The server does not merely echo back the message. It processes the message first, without gumming it up; and returns its version of what it read.
The websocket standard is not yet final and I have only tested on a limited number of advanced browsers that support the most recent (i.e. proposed final) version of the websocket protocol. It works fine using Google Chrome dev-channel Chromium 14 and above and Firefox 7 and above. You should also expect to be unsuccessful when trying to connect through a proxy server. Most proxy servers have not been updated to handle websockets and will deliver an incorrect request header, causing the request to fail.
You will not get a response from the server when using browsers that do not support close to final (or final) versions of the actual websocket standard protocol or if your request runs through a proxy server (which modifies the request headers such that they are no longer compliant). The browser application will say "CONNECTION REQUESTED ...." after you click the "Open Connection" button. After a wait period it will tell you that the application is "DISCONNECTED".
Opera is currently supporting an older draft of the websocket standard that the HLL websocket server does not support. I'll hold out a bit longer to see if Opera announces an upgrade soon. Opera has done excellent work in support of the HTML5 standard generally and I want to support people who use it. The older draft version of the websocket standard will not be the final version however, so I keep expecting to hear about an Opera upgrade any time now.
I've gone so far as to set up the web page for MSIE. 8 or above to load Google's plug-in to support websockets.
The demonstration server will be upgraded fairly frequently. I suspect there will be little chance that it will not be available for that reason when you try it, but it could happen. Important upgrades (such as the addition of http service) will be reported in this blog when they're ready. But because browser support for websockets is under development, I kind-of expect at least one major crash on at least one browser before it's all done. (Update: Not so much anymore. Things have been going smoothly.) I'm optimistic though. You should be too. If the web page loads a bit slowly, note that it isn't being delivered from the HLL WebSocket server.
You are invited to provide feedback. Simply add a comment under this article, or contact me by email.
If you have an appropriate web-browser, click here for the demonstration.
(January 12, 2013: Related article: WebSockets with Apache Tomcat and HLL)
Saturday, August 27, 2011
HLL Robot Application and SVG (Scalable Vector Graphics)
I chose SVG (Scalable Vector Graphics) to implement robot movement tracking in the robot HLL browser-based GUI. This link is to the history part of an SVG Primer from W3C. Its popularity assures continued support. (Good choice Roger. -- :) {pat on back}
Excerpt:
By the end of 1999, development of SVG had begun in earnest. Within two years, six subsequent working drafts appeared. IBM and Corel each released software that exported SVG. IBM released an SVG viewer and several software initiatives released SVG drawing packages for a variety of operating systems. Since that time support and endorsement has grown. By 2005, A Google search for "SVG" returned over 3.7 million links on the WWW. Table 1 compares these results with other technologies. By February 2009, all these numbers had increased considerably (HTML itself rose almost eightfold), but SVG had risen to 11.9 million web documents moving well ahead of Fortran which had risen to 8.6 million.
Excerpt:
By the end of 1999, development of SVG had begun in earnest. Within two years, six subsequent working drafts appeared. IBM and Corel each released software that exported SVG. IBM released an SVG viewer and several software initiatives released SVG drawing packages for a variety of operating systems. Since that time support and endorsement has grown. By 2005, A Google search for "SVG" returned over 3.7 million links on the WWW. Table 1 compares these results with other technologies. By February 2009, all these numbers had increased considerably (HTML itself rose almost eightfold), but SVG had risen to 11.9 million web documents moving well ahead of Fortran which had risen to 8.6 million.
| Query | Number of documents found |
|---|---|
"HTML" | 1,610,000,000 |
"PHP" | 454,000,000 |
"Java" (includes island) | 150,000,000 |
"Linux" | 86,400,000 |
"Perl" | 51,600,000 |
"JavaScript" | 49,900,000 |
"Unix" | 35,200,000 |
"C++" | 28,900,000 |
"SQL" | 21,200,000 |
"MySQL" | 20,300,000 |
"Pascal" (includes Blaise) | 14,500,000 |
"Visual Basic" | 8,330,000 |
"Fortran" | 5,350,000 |
"SVG" | 3,750,000 |
"COBOL" | 2,630,000 |
"Lisp" (includes stuttering) | 2,300,000 |
SMIL | 1,600,000 |
"awk" | 912,000 |
"VML" | 497,000 |
"ALGOL" | 489,000 |
"SNOBOL" | 40,900 |
Subscribe to:
Posts (Atom)