Or maybe they are not usefully described in the computer program metaphor.
DNA is not a program. For one, "program" implies that there is a fixed temporal order to the instructions. But organism development is initiated by cues from the environment, the order of execution is not stored anywhere. And its not even like subroutines, since what the DNA does is producing proteins. They are little machines that help to produce material substances when epigenetic mechanisms ask for them. The epigenome is more like a factory that produces according to information from the environment combined with its genetic capabilities than any sort of computer running a program. If you must view it as some turing machine, you need to include the whole environment, since much of the controlling information is "stored" there.
Isn't "line printer" also the name of printers that simply worked as typewriters, with solid types, rather than needles?
Anyway, the story above reminds me of when someone programmed an Altaire (in machine code, using dip switches and LEDs) to play music using the interference in the static noise from a radio put on top of the computer.
Yay! We just need some print spooling software to distribute one print job over 1,000 printer servers (doable) and find some way for the printed pages to end up in the right order. Perhaps stacking the printers on top of each other so they can all drop the pages on top of each other. Okay, so we need to put them in the elevator tower of an 84-story skyscraper... We can do that. Easy.;-)
The ElectriClerc Fully functional retrofitted prop computer
Built for a game of Cthulhu Lives! that has yet to be played, this piece was inspired by the retro-futuristic machines in the movie Brazil by Terry Gilliam. http://www.ahleman.com/Props/ElectriClerk.html
This sounds like a spin-off from some more ambitious AI project.
I did something similar once. When trying (and failing) to write an agent that could score texts based on whether they were "about the same thing," I ended up with a small application that could tell you whether a discussion in an IRC channel was "focused" or "unfocused" and thus whether what was being discussed was "interesting" or less so. It simply kept track of the size of the set of unique words used compared to the number of people talking, in a short memory model.
Luckily, I never got the idea to start a company and turn this into a product.
Personally I have the impression that "jerkiness" is something very subjective. If I don't think someone is being a jerk, what good is it to have a little device that thinks so?
Here's what I learned co-starting a few web companies in Sweden between '97 and '00, one of which was a bonafide dot-com (although we only burned ~$20M).
The money came mainly from the risk branches of investment firms started off of regular industry money. Risk capital typically is 5% of the total capital. This money is more or less expected to go out the windows, hence the "risk."
The model these guys worked from was to seed a company with some potential to attract more investors, then sell their shares at 10x the buying price as soon as that happened.
They were not morons. They didn't care if your business model made it likely that you would ever actually make money. It was a pyramid game. I seed this company, in the hope that another investor will step in and buy a large chunk of the stock for signifficantly more than I paid, before it all goes to hell. The second investor makes the same gamble, praying to God that there will be someone coming in after them, buying stock for an even higher price. And so on. It had nothing to do with business plans, except that plan was part of the general image of the company.
This is what the crazy expansions were about. The seeding investor needed the company to grow fast, so they get a fast return on their money. The entrepenours were usually a lot more sane in their plans. It was, in my experience (and I mingled with the founders of most European dot-coms) that it was the investors who insisted on opening offices on the most expensive streets, start branches in London, San Francisco, and Hong Kong, and hireing a thousand people, not the founders. Because that was the only way to quickly attract the next batch of investors.
So here are some conclusions: What really happened during the dot-com boom was that regular industry money were pumped into a lot of advertising companies and computer consultancy firms, to force along development projects with broken project plans and unrealistic time tables. But it put food on the tables of a lot of consultants. It might perhaps have advanced some web technologies (such as application servers) as well.
Eventually the investors realized the game wasn't working, and they pulled out. It was an investor-driven process, and most of the money was expendable. No big loss.
I simply test my site in IE, Opera, and Firefox, and assume that people not using them know what they're doing.;-) Well, if it works in those three without any browser-dependent code fixes, it usually works everywhere.
Because some sites will simply give you an error page if the agent is not IE or possibly Mozilla. Since Opera is highly IE compatible, it's meaningful to circumvent that "feature" of some sites and just pretend to be an IE browser. I hope this is a sign that Opera is now common enough so that the Opera people feel confident that site owners will not filter them out.
It is the copyright holders "rights" that are being upheld.
Well, that's a bit strained. The category header is obviously addressed to the readers of Slashdot, who judging by the responses here are not holders of copyrights, or care much for them. I think my interpretation is more likely, that some feel that free copying of copyrighted material is their right. And I don't believe that makes me "self-righteous" and certainly not "self-centered" (this isn't about me either way).
I see! I suppose if the server makes a request to the browser, the browser can respond by making a new HTTP request. Well, that could work.:-) I need to try that with something. Maybe make an updated version of Net Dice: http://kronocide.com/net_dice/:-P
Unless I've missed something very fundamental, AJAX too is bells and whistles on top of HTTP. It can work asynchronously in the background while you use the application, which makes a big difference in user experience, but there are still no actual server-initiated requests to the client over the network. It just might (or not) seem that way. If the server-side data is totally unpredictable, as with a chat client or a multi-user game, so that the browser can't precache intelligently, then the AJAX engine has no choice but to keep asking the server, "Any changes?" "Any changes now?" "What about now?" It does this in the background, so it may seem like "server push" to the user, but it's really exactly the situation I described above.
Again with a disclaimer that I might be totally lost here. I think not though.
Sorry if I'm being thick here, but are you saying that the XMLHttpRequest object initiates a session that's kept alive as long as you use the application, and communication can be initiated from client or server, like with a socket? It looks to me as if this object is simply a client-side implementation on top of the regular HTTP protocol. What part of it resides on the server, since it doesn't use HTTP? How do you initiate communication from the server?
If it is, as I believe is the case, that the XMLHttpRequest object is client-side magic only, and it still uses HTTP, then the client asks and the server answers, as usuall, and it can make one request at the time.
It looks to me as if Google Maps's uses XMLHttpRequest to simply load data in the background. That's smart, and a clear improvement, but it doesn't mean you can use XMLHttpRequest to write a chat client that will wait for the server to send a new chat message from another user and sit dormant until that happens. You still need to ask the server regularly, and nothing will happen in the browser unless you do. With less unpredictable content (such as maps or games) you can perhaps transfer some of the logic from the server to the client and make it even smarter and more dynamic, but that also makes the client thicker.
If I've missed something fundamental about the nature of the XMLHttpRequest object, I'd be happy to be educated. Any docs on server-side events with XMLHttpRequest would be highly appreciated.
Well, that is certainly an improvement in the sense that the application caches more in advance and does so with some intelligence, but there is no difference in principle. The server can still not initiate change on the client side, and this is a factor with all more complicated applications, especially multi-user ones or others where things change without the user doing anything.
Despite old futurists who need to keep the prophesies coming, and despite that some of it are good thoughts while others feel a bit 1997 (device independent content? XML anyone?), the most interesting development of the Internet the last 10 years is that less and less change is happening. IPv6 seems to never happen. What about multicasting everywhere? "The Semantic Web"? As the net grows, the technological inertia increases and radical changes seem to happen less and less frequently. Maybe not so much will happen in the near future as Kelly suggests. But embracing that hypothesis would put him out of a job.
Having developed all kinds of web apps since '96 for the exact reasons given in the article (simply the most convenient platform for distributed applications) I have learned that "that browsers don't give programmers full access to a computer's resources such as memory, process power and hard disk space" is not the most limiting aspect of web app development.
The most limiting aspect comes from one of the web's strengths, that it's based on a very simple request-response protocol. This means that you can't update the browser from the server. Instead of the server sending an event to the browser when something needs to change in the user interface, the UI needs to regularly ask the server if anything has changed. The consequence is the irritating, frequent page updates in web chats and similar applications, and "unnecessary" consumption of bandwidth.
This is why you need to use Java or Flash for more advanced applications. Then you can do pretty much anything, but the client also gets a whole lot thicker, and you can't use the web UI API shared by all browsers (form widgets, basically), which is one of the reasons web apps are so convenient to make.
I'm not saying this is something that should be "fixed," the request-response protocol is generally a good thing (and very unlikely to change anyway). I'm just saying that this is the big difference between designing web apps and desktop applications.
I bought an Amstrad NC100 "Notepad" for $20 at a flee-market a few years ago. I brought it along on my 3-month vacation to Samoa and wrote my travel diary on it. It uses a 1MB battery-backed SRAM PCMCIA card. Which means it starts instantly, and where I left off, if that's the setting I want. And I never need to think about "saving" what I write, because everything I type ends up in same place the files are. Also: no moving parts means it runs for 40 hours on 4 AA batteries. Solid state is teh w1n.
That's quite alright, Doohan delivered more than could be expected of him, during a long life (including participating in Normandie on D-Day and inventing the first version of Klingon). Here's to a wonderful, charming actor!
Yes, I suppose all those explanations are possible. Just a few comments:
Just like playing tunes using a floppy drive requires way more programming than playing them using the sound card + speakers. Does the size and complexity of a program to play tunes using the floppy mean that playing audio is so difficult or just that floppy is an inadequate device?
Interesting parallel. However, I don't think it really takes less programming to play music on the sound card, it's just that most of the programming is invisible to the ordinary "user." It may in fact contain more programming, it's just there in the device already. But I think the point is correct. Deep Blue beats most humans at chess and it's certainly a lot simpler than a brain, so specialization could work.
The spam filter is a really smart program that can build a great database out of available data. Take a few gigabytes of data (human DNA), add an uninhabited environment and in some time you have a civilisation. It doesn't mean data for all that was built was stored in the startup DNA. Just that it had good growth potential.
This seems to be the premise we all start from. The problem is that it's an over-simplification. We tend to discover after much trial and error that the data doesn't have the required properties to be sortable or distinguishable in the right ways, or that over time strange statistical artifacts emerge, or that the amount of data required to build a useable model is simply unachievable and impossible to work with. But I get your point, it's certainly a logical possibility.
Slashdot Mirror
Or maybe they are not usefully described in the computer program metaphor.
DNA is not a program. For one, "program" implies that there is a fixed temporal order to the instructions. But organism development is initiated by cues from the environment, the order of execution is not stored anywhere. And its not even like subroutines, since what the DNA does is producing proteins. They are little machines that help to produce material substances when epigenetic mechanisms ask for them. The epigenome is more like a factory that produces according to information from the environment combined with its genetic capabilities than any sort of computer running a program. If you must view it as some turing machine, you need to include the whole environment, since much of the controlling information is "stored" there.
Isn't "line printer" also the name of printers that simply worked as typewriters, with solid types, rather than needles?
Anyway, the story above reminds me of when someone programmed an Altaire (in machine code, using dip switches and LEDs) to play music using the interference in the static noise from a radio put on top of the computer.
Yay! We just need some print spooling software to distribute one print job over 1,000 printer servers (doable) and find some way for the printed pages to end up in the right order. Perhaps stacking the printers on top of each other so they can all drop the pages on top of each other. Okay, so we need to put them in the elevator tower of an 84-story skyscraper... We can do that. Easy. ;-)
With the help of computer technology we can now produce more paper documents faster! Talk of prophecies missing the mark. :-)
That's just because you haven't seen this:
The ElectriClerc
Fully functional retrofitted prop computer
Built for a game of Cthulhu Lives! that has yet to be played, this piece was inspired by the retro-futuristic machines in the movie Brazil by Terry Gilliam.
http://www.ahleman.com/Props/ElectriClerk.html
This sounds like a spin-off from some more ambitious AI project.
I did something similar once. When trying (and failing) to write an agent that could score texts based on whether they were "about the same thing," I ended up with a small application that could tell you whether a discussion in an IRC channel was "focused" or "unfocused" and thus whether what was being discussed was "interesting" or less so. It simply kept track of the size of the set of unique words used compared to the number of people talking, in a short memory model.
Luckily, I never got the idea to start a company and turn this into a product.
Personally I have the impression that "jerkiness" is something very subjective. If I don't think someone is being a jerk, what good is it to have a little device that thinks so?
Here's what I learned co-starting a few web companies in Sweden between '97 and '00, one of which was a bonafide dot-com (although we only burned ~$20M).
The money came mainly from the risk branches of investment firms started off of regular industry money. Risk capital typically is 5% of the total capital. This money is more or less expected to go out the windows, hence the "risk."
The model these guys worked from was to seed a company with some potential to attract more investors, then sell their shares at 10x the buying price as soon as that happened.
They were not morons. They didn't care if your business model made it likely that you would ever actually make money. It was a pyramid game. I seed this company, in the hope that another investor will step in and buy a large chunk of the stock for signifficantly more than I paid, before it all goes to hell. The second investor makes the same gamble, praying to God that there will be someone coming in after them, buying stock for an even higher price. And so on. It had nothing to do with business plans, except that plan was part of the general image of the company.
This is what the crazy expansions were about. The seeding investor needed the company to grow fast, so they get a fast return on their money. The entrepenours were usually a lot more sane in their plans. It was, in my experience (and I mingled with the founders of most European dot-coms) that it was the investors who insisted on opening offices on the most expensive streets, start branches in London, San Francisco, and Hong Kong, and hireing a thousand people, not the founders. Because that was the only way to quickly attract the next batch of investors.
So here are some conclusions: What really happened during the dot-com boom was that regular industry money were pumped into a lot of advertising companies and computer consultancy firms, to force along development projects with broken project plans and unrealistic time tables. But it put food on the tables of a lot of consultants. It might perhaps have advanced some web technologies (such as application servers) as well.
Eventually the investors realized the game wasn't working, and they pulled out. It was an investor-driven process, and most of the money was expendable. No big loss.
But it's not a right.
I simply test my site in IE, Opera, and Firefox, and assume that people not using them know what they're doing. ;-) Well, if it works in those three without any browser-dependent code fixes, it usually works everywhere.
Because some sites will simply give you an error page if the agent is not IE or possibly Mozilla. Since Opera is highly IE compatible, it's meaningful to circumvent that "feature" of some sites and just pretend to be an IE browser. I hope this is a sign that Opera is now common enough so that the Opera people feel confident that site owners will not filter them out.
It is the copyright holders "rights" that are being upheld.
Well, that's a bit strained. The category header is obviously addressed to the readers of Slashdot, who judging by the responses here are not holders of copyrights, or care much for them. I think my interpretation is more likely, that some feel that free copying of copyrighted material is their right. And I don't believe that makes me "self-righteous" and certainly not "self-centered" (this isn't about me either way).
Think what you will about it, but recieving a free copy of something someone else has invested time and money to produce is not a "right."
I see! I suppose if the server makes a request to the browser, the browser can respond by making a new HTTP request. Well, that could work. :-) I need to try that with something. Maybe make an updated version of Net Dice: :-P
http://kronocide.com/net_dice/
It's funny, I wrote almost the exact some post as I did above when an article about AJAX was posted here. I think that article linked to this one:r chives/000385.php
http://www.adaptivepath.com/publications/essays/a
Unless I've missed something very fundamental, AJAX too is bells and whistles on top of HTTP. It can work asynchronously in the background while you use the application, which makes a big difference in user experience, but there are still no actual server-initiated requests to the client over the network. It just might (or not) seem that way. If the server-side data is totally unpredictable, as with a chat client or a multi-user game, so that the browser can't precache intelligently, then the AJAX engine has no choice but to keep asking the server, "Any changes?" "Any changes now?" "What about now?" It does this in the background, so it may seem like "server push" to the user, but it's really exactly the situation I described above.
Again with a disclaimer that I might be totally lost here. I think not though.
Sorry if I'm being thick here, but are you saying that the XMLHttpRequest object initiates a session that's kept alive as long as you use the application, and communication can be initiated from client or server, like with a socket? It looks to me as if this object is simply a client-side implementation on top of the regular HTTP protocol. What part of it resides on the server, since it doesn't use HTTP? How do you initiate communication from the server?
If it is, as I believe is the case, that the XMLHttpRequest object is client-side magic only, and it still uses HTTP, then the client asks and the server answers, as usuall, and it can make one request at the time.
It looks to me as if Google Maps's uses XMLHttpRequest to simply load data in the background. That's smart, and a clear improvement, but it doesn't mean you can use XMLHttpRequest to write a chat client that will wait for the server to send a new chat message from another user and sit dormant until that happens. You still need to ask the server regularly, and nothing will happen in the browser unless you do. With less unpredictable content (such as maps or games) you can perhaps transfer some of the logic from the server to the client and make it even smarter and more dynamic, but that also makes the client thicker.
If I've missed something fundamental about the nature of the XMLHttpRequest object, I'd be happy to be educated. Any docs on server-side events with XMLHttpRequest would be highly appreciated.
Well, that is certainly an improvement in the sense that the application caches more in advance and does so with some intelligence, but there is no difference in principle. The server can still not initiate change on the client side, and this is a factor with all more complicated applications, especially multi-user ones or others where things change without the user doing anything.
Despite old futurists who need to keep the prophesies coming, and despite that some of it are good thoughts while others feel a bit 1997 (device independent content? XML anyone?), the most interesting development of the Internet the last 10 years is that less and less change is happening. IPv6 seems to never happen. What about multicasting everywhere? "The Semantic Web"? As the net grows, the technological inertia increases and radical changes seem to happen less and less frequently. Maybe not so much will happen in the near future as Kelly suggests. But embracing that hypothesis would put him out of a job.
Having developed all kinds of web apps since '96 for the exact reasons given in the article (simply the most convenient platform for distributed applications) I have learned that "that browsers don't give programmers full access to a computer's resources such as memory, process power and hard disk space" is not the most limiting aspect of web app development.
The most limiting aspect comes from one of the web's strengths, that it's based on a very simple request-response protocol. This means that you can't update the browser from the server. Instead of the server sending an event to the browser when something needs to change in the user interface, the UI needs to regularly ask the server if anything has changed. The consequence is the irritating, frequent page updates in web chats and similar applications, and "unnecessary" consumption of bandwidth.
This is why you need to use Java or Flash for more advanced applications. Then you can do pretty much anything, but the client also gets a whole lot thicker, and you can't use the web UI API shared by all browsers (form widgets, basically), which is one of the reasons web apps are so convenient to make.
I'm not saying this is something that should be "fixed," the request-response protocol is generally a good thing (and very unlikely to change anyway). I'm just saying that this is the big difference between designing web apps and desktop applications.
I bought an Amstrad NC100 "Notepad" for $20 at a flee-market a few years ago. I brought it along on my 3-month vacation to Samoa and wrote my travel diary on it. It uses a 1MB battery-backed SRAM PCMCIA card. Which means it starts instantly, and where I left off, if that's the setting I want. And I never need to think about "saving" what I write, because everything I type ends up in same place the files are. Also: no moving parts means it runs for 40 hours on 4 AA batteries. Solid state is teh w1n.
Get your l33t sp34k right.
Racist.
"In America sex is an obsession, in other parts of the world it is a fact."
--Marlene Dietrich
That's quite alright, Doohan delivered more than could be expected of him, during a long life (including participating in Normandie on D-Day and inventing the first version of Klingon). Here's to a wonderful, charming actor!
Yes, I suppose all those explanations are possible. Just a few comments:
Just like playing tunes using a floppy drive requires way more programming than playing them using the sound card + speakers. Does the size and complexity of a program to play tunes using the floppy mean that playing audio is so difficult or just that floppy is an inadequate device?
Interesting parallel. However, I don't think it really takes less programming to play music on the sound card, it's just that most of the programming is invisible to the ordinary "user." It may in fact contain more programming, it's just there in the device already. But I think the point is correct. Deep Blue beats most humans at chess and it's certainly a lot simpler than a brain, so specialization could work.
The spam filter is a really smart program that can build a great database out of available data. Take a few gigabytes of data (human DNA), add an uninhabited environment and in some time you have a civilisation. It doesn't mean data for all that was built was stored in the startup DNA. Just that it had good growth potential.
This seems to be the premise we all start from. The problem is that it's an over-simplification. We tend to discover after much trial and error that the data doesn't have the required properties to be sortable or distinguishable in the right ways, or that over time strange statistical artifacts emerge, or that the amount of data required to build a useable model is simply unachievable and impossible to work with. But I get your point, it's certainly a logical possibility.
So I get downmoderated because I want to give some positive feedback but don't have any modpoints? Gee, thanks.