Showing posts with label Javascript. Show all posts
Showing posts with label Javascript. Show all posts
Wednesday, August 22, 2007
Javascript this
One of the most frustrating things about Javascript is its handling of "this," which you first encounter when attaching events to objects, and next when you try to pass member functions to other member functions within an object, and then try to call them from another member function, like in this (contrived) prototype:
You'd expect to see an alert window with "Hello drblast!" in it, but instead, an error occurs. The reason is that "this" is set to the global "this" object when you call the myFunc function from within handlerFunc(), since the name "myFunc" is not a member of any object, even though it's representing a member function.
To get this to work, you need to set a member variable to the member function you want to call, as follows:
Now this will be set properly, and you'll get an alert window with message as expected.
...
sayHello: function(text)
{
alert("Hello " + text);
},
handlerFunc: function(myFunc)
{
//call a member function
myFunc('drblast!');
},
doAlert: function()
{
this.handlerFunc(this.sayHello);
}
...
You'd expect to see an alert window with "Hello drblast!" in it, but instead, an error occurs. The reason is that "this" is set to the global "this" object when you call the myFunc function from within handlerFunc(), since the name "myFunc" is not a member of any object, even though it's representing a member function.
To get this to work, you need to set a member variable to the member function you want to call, as follows:
...
handlerFunc: function(myFunc)
{
//call a member function
this.tempFunc = myFunc;
this.tempFunc('drblast!');
},
...
Now this will be set properly, and you'll get an alert window with message as expected.
Wednesday, August 15, 2007
What's old is new again
While looking for some info on vi, I found the following interview with Bill Joy, from around 1984:
What's particularly striking about this quote is that he was extraordinarily prescient and wayyyy off simultaneously.
He was talking about how people would use computing devices in the future, and his idea was that instead of mass storage in a small format, we'd have thin clients where even the operating system was served from a remote machine, very much like the Unix consoles he was working on at the time. (at 1200 baud, apparently)
So let's look at what happened. Just as he predicted, hard drives have gotten cheaper and smaller and now everyone has a portable one (iPod). However, the network latency and throughput has not yet caught up to to hard drive speed to where it's feasible to do all of your computing over a network link. You still need an operating system. But he knew that would probably be the case, because so many people wanted it to be like that.
So it seems like he was right on, except that it's obvious that he was thinking that big servers and thin clients would continue to exist. Even though he talked about Apple's new Mac in the interview, I don't think he predicted the huge increase in the performance of cheap hardware.
It's easy to see why. A million times faster is an easy concept to understand. If I told you computers will be a million times faster in 20 years, you'd shrug and say, "sure, that sounds about right." But what neither of us can envision is what people will actually do with that horsepower.
I guarantee you that if you went back 20 years and told people that everyone will own a multi-core CPU that runs at 3GHz, and that with all that horsepower, the most popular application development environment is an interpreted scripting language that makes asynchronous network calls to grab data and display it on a tree-based document display program that runs on top of an graphical windowing system (which, coincidentally, already has all of the widgets to do all of those things the browser does), which is implemented in multiple layers that span multiple processes that all run on top of the operating system, they'd look at you like you were crazy. And yet that's exactly what we're doing with Javascript, which in effect, is a way to make today's lightning fast hardware behave just like the network computer Bill Joy described.
He was exactly right, but he never predicted there would be five or six layers in between pages of RAM and the user's data.
Here's the big question: if you were develop a system to do what web browsers and Javascript do from scratch, would it look anything like a web browser and Javascript? My guess is no. I'm not sure if that would be a good thing or not.
So. . .here's my prediction, taking into account the pace of hardware development and the history of software development. In 20 years, cheap hardware will be ridiculously fast, but it will still look very much like Intel hardware today. We'll have many, many CPU cores to work with, but nobody will use a parallel programming language designed to take advantage of multiple cores. Instead, virtualization (i.e. VMware, Xen) will be integreted into the operating system, and each process will run on its own virtual machine.
Each web browser will have been expanded into a full blown widget toolkit and have merged in something that looks like Flash, but there will still be multiple incompatible browsers. The latest craze will be a browser compatibility layer written in a programming language that compiles to "raw Javascript", and it will reduce the performance of applications but allow you to use them anywhere.
People will set about re-writing a version of Photoshop in the new compatibility layer, and everyone will wonder why they'd do that, when the current version of Photoshop runs in Internet Explorer just fine.
REVIEW: You mention everything but disks.
JOY: You might want to page over satellite telephone... Page fault, and the computer makes a phone call. Direct broadcast or audio disk - that's the technology to do that. It's half a gigabyte - and you get 100 kilobyte data rate or a megabyte or something. I don't remember. You can then carry around with you all the software you need. You can get random data through some communications link. It is very like Dick Tracy. Have you seen these digital pagers? You can really communicate digital information on a portable.
I don't think you need to have a disk with you. There are so many people who believe that you need to have a disk that you'll be able to have one because they'll make it cheap. That's the way things work. It's not what's possible but what people believe is possible...
What's particularly striking about this quote is that he was extraordinarily prescient and wayyyy off simultaneously.
He was talking about how people would use computing devices in the future, and his idea was that instead of mass storage in a small format, we'd have thin clients where even the operating system was served from a remote machine, very much like the Unix consoles he was working on at the time. (at 1200 baud, apparently)
So let's look at what happened. Just as he predicted, hard drives have gotten cheaper and smaller and now everyone has a portable one (iPod). However, the network latency and throughput has not yet caught up to to hard drive speed to where it's feasible to do all of your computing over a network link. You still need an operating system. But he knew that would probably be the case, because so many people wanted it to be like that.
So it seems like he was right on, except that it's obvious that he was thinking that big servers and thin clients would continue to exist. Even though he talked about Apple's new Mac in the interview, I don't think he predicted the huge increase in the performance of cheap hardware.
It's easy to see why. A million times faster is an easy concept to understand. If I told you computers will be a million times faster in 20 years, you'd shrug and say, "sure, that sounds about right." But what neither of us can envision is what people will actually do with that horsepower.
I guarantee you that if you went back 20 years and told people that everyone will own a multi-core CPU that runs at 3GHz, and that with all that horsepower, the most popular application development environment is an interpreted scripting language that makes asynchronous network calls to grab data and display it on a tree-based document display program that runs on top of an graphical windowing system (which, coincidentally, already has all of the widgets to do all of those things the browser does), which is implemented in multiple layers that span multiple processes that all run on top of the operating system, they'd look at you like you were crazy. And yet that's exactly what we're doing with Javascript, which in effect, is a way to make today's lightning fast hardware behave just like the network computer Bill Joy described.
He was exactly right, but he never predicted there would be five or six layers in between pages of RAM and the user's data.
Here's the big question: if you were develop a system to do what web browsers and Javascript do from scratch, would it look anything like a web browser and Javascript? My guess is no. I'm not sure if that would be a good thing or not.
So. . .here's my prediction, taking into account the pace of hardware development and the history of software development. In 20 years, cheap hardware will be ridiculously fast, but it will still look very much like Intel hardware today. We'll have many, many CPU cores to work with, but nobody will use a parallel programming language designed to take advantage of multiple cores. Instead, virtualization (i.e. VMware, Xen) will be integreted into the operating system, and each process will run on its own virtual machine.
Each web browser will have been expanded into a full blown widget toolkit and have merged in something that looks like Flash, but there will still be multiple incompatible browsers. The latest craze will be a browser compatibility layer written in a programming language that compiles to "raw Javascript", and it will reduce the performance of applications but allow you to use them anywhere.
People will set about re-writing a version of Photoshop in the new compatibility layer, and everyone will wonder why they'd do that, when the current version of Photoshop runs in Internet Explorer just fine.
Tuesday, August 14, 2007
So here we are
I never thought I'd be doing this, but it's become apparent that blogs about computer programming are extremely useful, not to mention ultra-hip and will have the chicks at Starbucks flocking over to my non-hip, non-Mac laptop to see what I'm writing about. I'm just kidding, the chicks would have to flock to Dunkin Donuts to find me. It looks like I still need to work on the color scheme and shrink the column width down so that about three words will fit into each line, though. Then I'll feel smarter.
I started writing a vi-clone in Javascript yesterday. It's still in its infancy, but the cursor controls and insert and command mode work, so it's just a matter of adding commands to make it complete. The difficult part was realizing that no amount of trying would make a <textarea> behave like I wanted it to, so I had to use a <div> and implement a line editor from scratch.
Javascript is quickly becoming one of my favorite languages, although it still has its quirks. It's extremely flexible, and has first class functions, which are making their way up the list of mandatory features for me.
The most glaring problem that Javascript has is its annoying treatment of "this." I'm especially peeved that you can't attach a method of an object to an event handler using addEventListener. Yes, there are ways around this, but this should be easy. Right now, it makes it difficult to encapsulate everything in objects, so you always run the risk of name collisions by using global function names.
Of course, you could add a prefix to everything, like vieditor_keypressed(ev){}, but this is 2007, and the namespace problem has been solved for years.
Anyway, that's a small complaint. I think Javascript gets a bad name mostly because of all of the browser incompatibilities, but it's minimal work to write a decent layer to hide those.
I started writing a vi-clone in Javascript yesterday. It's still in its infancy, but the cursor controls and insert and command mode work, so it's just a matter of adding commands to make it complete. The difficult part was realizing that no amount of trying would make a <textarea> behave like I wanted it to, so I had to use a <div> and implement a line editor from scratch.
Javascript is quickly becoming one of my favorite languages, although it still has its quirks. It's extremely flexible, and has first class functions, which are making their way up the list of mandatory features for me.
The most glaring problem that Javascript has is its annoying treatment of "this." I'm especially peeved that you can't attach a method of an object to an event handler using addEventListener. Yes, there are ways around this, but this should be easy. Right now, it makes it difficult to encapsulate everything in objects, so you always run the risk of name collisions by using global function names.
Of course, you could add a prefix to everything, like vieditor_keypressed(ev){}, but this is 2007, and the namespace problem has been solved for years.
Anyway, that's a small complaint. I think Javascript gets a bad name mostly because of all of the browser incompatibilities, but it's minimal work to write a decent layer to hide those.
Subscribe to:
Comments (Atom)