Perl is still a great replacement for shell scripts, sed and awk. It's native regex support is ahead of it's time. You can do crazy string manipulation and statistical gathering with no effort at all. A bunch of web log parsers were written in Perl and it's easy to see why, because the language was designed for that sort of purpose. Perl is to server administration and string parsing what PHP is to CGI.
strict prevents you from doing some things with hashes which are valid code, so it came as a shock to once discover that strict itself was the bug.
I hate how much of the stuff strict warns over doesn't stop the program from actualy working. It's like if the program would have ran fine anyway just run and be done with it so I can get on with my life. It's perl, it's not like it's ever going to be a piece of fine jewelry.
It's not as if the frameset/location.replace() method is SLLLLOOOOOOOOWWWWWERRR than HTTPRequest.
The thing that's realy disapointing about HTTPRequest is that it doesn't have a persistant server connection. You still have to continuously request updates from the server which is like puting a bag over an ugly girl's head. As long as we're playing the compromise game why should we spend our resources making it an official compromise.
You can have persistant server connections with java applets. Why couldn't that have become the fad? That would have atleast been a little ambitious.
You can tell this is a fad because 1) this technique has been available for years this with Java applets, iframes and dynamic script src includes 2) it's not beneficial for 99% of the websites out there 3) it requires extra work to make the process intuitive to users 4) it's more costly to develop in that it takes longer and requires more smarts, and most of the time it isn't going to pay for itself, because simply getting rid of a page reload in the age of broadband doesn't itself improve the underlying quality of the website. The success of most websites still has 99% to do with content and 1% or less with UI aspects. Look at Craig's List or this website.
The reason the technique has become popular all of the sudden is because Google has been incorperating it alot and someone gave it a name. Before the name AJAX came along you would have had to describe it with a sentance and that doesn't fit in a headline.
Before HTTPRequest you could have as easily done an location.replace() to a CGI in a hidden frame and had the CGI's response do a callback to a function in the calling window and it would work exactly the same way. When you use the location.replace() method you avoid the clicking sound and the history entry when calling the hidden CGI. You can even use an iframe if you want to avoid using a frameset. This technique has been available since the 90's. I might still prefer this method because it's more robust and there's no need for compatability checking.
Slashdot Mirror
Perl is still a great replacement for shell scripts, sed and awk. It's native regex support is ahead of it's time. You can do crazy string manipulation and statistical gathering with no effort at all. A bunch of web log parsers were written in Perl and it's easy to see why, because the language was designed for that sort of purpose. Perl is to server administration and string parsing what PHP is to CGI.
strict prevents you from doing some things with hashes which are valid code, so it came as a shock to once discover that strict itself was the bug. I hate how much of the stuff strict warns over doesn't stop the program from actualy working. It's like if the program would have ran fine anyway just run and be done with it so I can get on with my life. It's perl, it's not like it's ever going to be a piece of fine jewelry.
It's not as if the frameset/location.replace() method is SLLLLOOOOOOOOWWWWWERRR than HTTPRequest.
The thing that's realy disapointing about HTTPRequest is that it doesn't have a persistant server connection. You still have to continuously request updates from the server which is like puting a bag over an ugly girl's head. As long as we're playing the compromise game why should we spend our resources making it an official compromise.
You can have persistant server connections with java applets. Why couldn't that have become the fad? That would have atleast been a little ambitious.
You can tell this is a fad because 1) this technique has been available for years this with Java applets, iframes and dynamic script src includes 2) it's not beneficial for 99% of the websites out there 3) it requires extra work to make the process intuitive to users 4) it's more costly to develop in that it takes longer and requires more smarts, and most of the time it isn't going to pay for itself, because simply getting rid of a page reload in the age of broadband doesn't itself improve the underlying quality of the website. The success of most websites still has 99% to do with content and 1% or less with UI aspects. Look at Craig's List or this website. The reason the technique has become popular all of the sudden is because Google has been incorperating it alot and someone gave it a name. Before the name AJAX came along you would have had to describe it with a sentance and that doesn't fit in a headline. Before HTTPRequest you could have as easily done an location.replace() to a CGI in a hidden frame and had the CGI's response do a callback to a function in the calling window and it would work exactly the same way. When you use the location.replace() method you avoid the clicking sound and the history entry when calling the hidden CGI. You can even use an iframe if you want to avoid using a frameset. This technique has been available since the 90's. I might still prefer this method because it's more robust and there's no need for compatability checking.