This windows cloud computing stuff is already used to send millions of emails a day and so on. The product itself really isn't news, the only news is that Ballmer is finally giving it a product name so we can talk about it more effectively in the media.
For a list of computers participating in the Windows Cloud, go here and request an rsync feed for the XBL.
> You don't have to tell us. Nobody here reads the articles or > the summaries. Hell, we barely read the comments they're responding to.
I couldn't agree more. The fact that Barrack Obama thinks he can win the election without being underhanded tells me he doesn't have the stones to be a world leader.
Nit: The 1541's directory structure lived on track 18, not the C64's.
Track 18 was chosen because it was in the middle. That was the typical way Commodore did it back in the day -- So 4040s, 2031s, 1540s and 1541s had track 18 directories, but 8050s, 8250s, and SFD-1001s had them on track 40.
No idea where the harddrive dirs were, I couldn't afford one.
I think your calculus teacher was probably adjusting your scores by sliding around the marks distribution to achieve a specific mean by the end of the semester.
Then you need to change hosting providers, once more, and finally.
Not providing shell access to a web hosting account is, in my opinion, a crime.
This is why I always deal with mom-n-pop ISPs. "Hey, can I get a shell account on that box?"
Well, plus then I can always say, "If you give me X I'll consult for you on Y"
Even if shell is a little hard to get, there's plenty of places that will let you run PHP programs.
30 seconds of googling turned up phpwebhosting.com, which offers php, mysql, shell, perl, python, ruby-on-rails, a gig of disk and email. For ten bucks a month.
> I've long thought Javascript has been a much maligned language and have sorely felt the > lack of a good command line Javascript... combined with Tk, well, I look forward to what > you come up with most eagerly.
You might have to wait a while -- but I'll have something eventually. GUI isn't on the paid-to-develop project plan, but most of the other important bits are. Which is great, I'm getting paid to write software I'd write for free if I could afford to do so. (Shhhh! Don't tell anybody!;)
> Me too, the last time I did major GUI work was when I wrote Workbench for the Amiga
Did you just say you wrote Workbench for the Amiga? Uhm, listen.. if you're ever in my neighbourhood, ah, dinner's on me.
> But wait, you mention REXX? I wasn't aware that was still in active use, outside the mainframe world..
Those crazy OS/2 guys. You can kill their OS, but not their spirit.:)
I haven't written anything in Object REXX (yes, you heard that right) but it looks like a pretty decent language. One of the guys I work with was heavy in OS/2 until just a couple of years ago.
Me, I haven't actually used REXX since the VM/CMS days. And back then.. I didn't know enough to appreciate it.
Your problem isn't any of the ones you listed. You need to be writing your own back-end applications so you can roll simple (SIMPLE!!!) shit like a guestbook on your own. If you have a year of CS under your belt, you are MORE than qualified to write a guest book.
Doesn't matter what the backend language is, asp.. php... UNIX shell, perl... Control the backend apps, you control the site. Let the hosting provider provider your guestbook? Puh-lease. You'll always be at their mercy because you'd might as well be writing your guestbook-and-similar crap.
Plus you might actually learn some CS problem solving techniques by writing apps. You aren't going to learn CS.squat tweaking HTML and CSS until you're blue in the face.
> Maybe it's just me, but I don't like the FCC making rules that cannot > be read because some company has a copyright on it.
Reminds me of an episode of Numb3rs last season.
(paraphrasing)
FBI Agent: You're under arrest for exporting classified research Pakistani Scientist: I didn't know my research was restricted! How was I supposed to know?? FBI Agent: The list of classified information is classified
Actually, not that it wasn't slow, just that it didn't contain certain trivial optimizations. But my assumption is that once it's run a couple of times, the Hotspot code (JIT and adaptive optimizers) will have worked its magic on Rhino, so those optimizations almost certainly become moot over the long term.
That said, if i really cared to have a text-editor-capable OS boot quickly, _and_ it needed FAT32.
Hmm.
Is VFAT close enough for ya? Win98 boot disk transmuted onto a USB dongle with the VFAT driver in the config.sys. Boot only to command.com, not the full OS.
It'll probably take longer for your box to POST than to boot that puppy.
Yes, but you've missed the key point. (If I understand Rhino correctly, which I think I do)
The javascript is not compiled over-and-over again with the java compiler. Rhino is. Then Rhino emits java byte code which gets the hotspot/jit goodness.
This means that the quality of the optimizations used by the compiler which compiled Rhino is not nearly as relevant as the quality of the bytecode emitted by Rhino, and that the quality of the JIT java bytecode thing probably dominates.
Note, of course, that this is all speculation. I don't use Rhino nor Java.
> There are already Tk bindings for Scheme and Perl as well as Tcl, why not > implement Javascript/Tk and avoid all the heavy lifting?
In principle? No reason, other that it had never crossed my mind.
Like I said, I'm not a GUI guy.:)
Somehow, I have managed to avoid GUI work for years and years and years and years... I've done GUIs with VB4, lots of web apps, I wrote an X widget once in school... But holy moly that was a long time ago.
On paper your proposal makes a LOT of sense. In fact, the bindings for Lua and REXX will probably provide significant guidance.
I started a major JavaScript-engine-using project over a year ago.
Boss said: are you sure it will be fast enough? I said: Between Moore's law and the javascript performance increase that's due, I'm sure it will be.
(Note that at the time ActionMonkey had just been announced, it was a pretty safe bet it woulda arrive)
So far, so good. Another 8 months or so and I should have a product. And it's already in the right performance neighbourhood *without* all this cool new stuff.
> one of the things about the code is that it looks like it is trying to be OO but in straight C
I can totally see how you would come to that conclusion. But, in my opinion that's *not* what it's doing -- it's implementing an OO system (JavaScript) in C. Subtle shade of difference, but an important one. I've written OO code in straight C, and it was far more function pointery.:)
There are couple of things which make writing for jsapi different than your average run-of-the-mill C code.
1. Garbage Collection: If you give memory to the JS engine, you must ensure it will be freed properly... Best analogy I can think of is writing VB4-style C DLLs. If you pass strings back to the non-C language and expect it to manage the string's lifetime, you'd better allocated with the non-C language's allocator.
2. Finalizers: IF you write C classes for JS which absolutely cannot be managed by the garbage collector, you need to write a finalizer for the GC to call
3. What you're writing will usually be a method for a JS object. That's not really relevant to OO-ness from the C point of view.
4. If not a method, it'll probably a getter/setter. Which I consider to be equivalent: prop/method==false dichotomy.
Oh - I just had another analogy -- writing jsapi code for spidermonkey is virtually equivalent to writing JNI code for java. Actually, I'll bet you could make jsapi bindings for cxxwrap or swing. Not that I think that's a good idea.... simply wrapping system libs sucks, I prefer to think them through and create modules with a true javascript-flavour-idiom-blahblahblah.
The other references you've made sound like you've had a look through some of the engine itself, rather than trying to use the API implemented in jsapi.h. I'd... ah, not recommend doing that, unless you're trying to learn "cool tricks". And there are bunch of them in there! But you don't need to read any of them to do productive work.
Also, most of the crazy macros you see coming out of there? You can ignore them and use JS_* functions defined in the API and defined on developer.mozilla.org. MOST of the macro-laced code requires "private knowledge" to prove correct and saves only on function call overhead. Personally, I don't need speed anywhere as bad as I need solid code, so I don't use 'em unless it's impossible not to (rarely if ever) or the profiler tells me I need to (hasn't happened yet).
So, ah. Last two paragraphs in summary: jsapi - good. Internals of spidermonkey - highly optimized at the source-code level. Not good reading, also makes maintenance a challenge.
(for anyone familiar with jsapi reading this -- bz? -- the macro stuff I mentioned, I mean things like the difference between JSVAL_TO_STRING(vp) vs. JS_ValueToString(cx, vp)... They are equivalent in all outside-of-the-interpreter cases, except maybe the branch call back [cx not in rt?], IF vp is a jsstring, ignoring the function call overhead. But if vp is not a jsstring, the behaviour is NOT consistent with what I think non-spidermonkey-maintaining-programmers would expect)
I don't know what the current state of the art is, but last I looked Rhino was still the fastest javascript implementation, IF you discounted the JVM start up.
IIRC, Rhino compiles JavaScript into native Java byte code, which then gets the JIT magic sprinkled on it by the JVM pixies.
So the quality of the Java compiler is really not all that relevant, because the code compiled by the compiler only compiles the javascript code once, making the quality of the compiler effectively order(1)... and given sufficiently large N, nobody cares about k.
Now, a javascript->x86 compiler.. that would be interesting. Although javascript->C or javascript->gcc-intermediate would be much nicer, because I don't live in x86-land.
I know nothing of WebKit, so I will not speak of it.
It is currently possible to use SpiderMonkey at the level of ff3 for real work. There's a bit of a learning curve, but it's totally usable. In theory, anything you write for SpiderMonkey-trunk will be usable with the new tracing stuff they've built. That's not in CVS, it's in hg (mercurial), and I'm not sure what state it's in right now. I'm guessing it's probably usable, too. Oh, I think the tracing code also requires a C++ compiler, although I could be wrong.
> I'd like to see a JavaScript engine with pluggable modules (sort of like TCL) and possibly a nice accessible GUI (like TK).
I have been working on something like this, and will get back it to it sooner or later. Probably early november. Unfortunately, great swaths of it is closed (it wraps trade secret libraries), but the basic infrastructure and some of the classes are open. You use it basically like any other UNIX shell interpreter.
When I get back to this project, I plan on more rigorously defining the module loading code to make it easier to extend. Right now, it's pretty easy to compile them in, but there is no good way to load DSOs and so forth. I also want to load JavaScript-language modules more elegantly.
If you want to see my early work -- which is not really all that useful unless you're planning on writing more classes in C to expose whatever it is you want to work with -- go here: http://www.page.ca/~wes/opensource/
As for GUI, I don't really know anything about GUI development, but I'd totally be up for a collaboration if somebody wanted to do simple widgets. I was thinking of ripping apart Dialog for X (nee cdialog) and cloning that functionality someday.
As of right now, I _do_ have a trivial curses interface which can put windows on a terminal, scroll output through them, and so forth. (Not in the link -- insufficient polish). I used it to put together a simple debugging environment where I type JavaScript code and it prints the results in a different window. Basically, like the debug window pair that shipped with QuickBasic 4.5.
Oh -- and the stuff I'm working on is UNIX only. Well, it should run under Cygwin.
I have also played with wsh under Win32. There is a lot of cool stuff you can do, although learning the win32 api appears to be a large and daunting task. I used it to write a simple remote media player for my house, where I could drag a file icon to a JavaScript program on my desktop, which spooled it to a UNIX server in the basement for pickup by a windows box in my living room which in turn would play the content through my home theatre... via another JavaScript program, using the windows media player control.
> implementation issue, and not a JavaScript issue.
This is a common error, which I find myself correcting regularly. It's clearer to me than the average joe, because I write non-browser JavaScript on a regular basis.
> That's why I don't like the idea of having all JavaScript includes behaving as if it's one giant script.
The problem there is that the browser inventors came up with the web-page = program-scope equivalence, with only one program isolation container: iframe. Basically, document is to process as web-page is to operating system.
Furthermore, JavaScript was meant to be used in the browser to only to manipulate the document.. And it doesn't have to be JavaScript. It could just as easily be VBScript...or even lua or python if somebody wrote the bindings and banged it into a browser.
> I'm not sure that this new trend of moving to separate processes will fix anything in these cases, because you can't > really differentiate between your code and someone else's.
Right. This problem isn't going to be solved without inventing a new container. Or at least making use of the crappy one we have now (iframe).
> Again, browsers have changed a lot over the years, and some methods that worked > in the past no longer function these days
JavaScript methods, or DOM methods called from JavaScript? There is a huge difference!
JavaScript methods are things like Array.push or String.length. DOM methods are things like document.getElementById. Don't blame the DOM on JavaScript. Just like you shouldn't blame MFC on C++.
> Scripts that were perfectly legal a couple years ago will throw some kind of security exception, > and that causes the whole site to grind to a halt.
That's because the browsers no longer allow those things. Has nothing to do with the language. I'm sure you'll get the same exceptions calling those same methods from VBScript.
Think of it this way, if root changes a file in your home directory so that you can no longer edit it... is that a problem with bash, or root? Me, I'd grab a pipe, find root, and bash him with it.
I don't mean to come off as a pedant, I'm trying to help people see the world as it really is... so that JavaScript can be taken more seriously, AND so that the people in charge of the browser DOM (etc) design will come up with better application containers and method passing techniques.
(Ever tried to write an AJAX app that spanned domains? It's ridiculously difficult and requires extensive hoop jumping)
I recently took over a large body web code from another developer. In order to meet deadlines, I'm working nights and weekends (oh, man, I SO THOUGHT I'd left that behind with my 20s). Needless to say, I'm not happy. To make matters worse, I got pulled off a fun project to work on web shit. With a PHP back end.
So, anyhow.. my kid comes up to me the other day and says, "Boy... you sure swear a lot when you're working!"
And 99% of my swearing is.. you guessed it. WTF?!?!?!?!!!
Slashdot Mirror
This windows cloud computing stuff is already used to send millions of emails a day and so on. The product itself really isn't news, the only news is that Ballmer is finally giving it a product name so we can talk about it more effectively in the media.
For a list of computers participating in the Windows Cloud, go here and request an rsync feed for the XBL.
> You don't have to tell us. Nobody here reads the articles or
> the summaries. Hell, we barely read the comments they're responding to.
I couldn't agree more. The fact that Barrack Obama thinks he can win the election without being underhanded tells me he doesn't have the stones to be a world leader.
664 blocks at 256 bytes, not including the directory, which means 169984 bytes. 170K in harddrive math, 166K by everybody else's math.
???
Anything that's easy to implement with a library is equally easy to implement without a library.
cat library/*.[ch] >> main.c
No. The 1571 could do either GCR or MFM. MFM support was added so that CP/M programs from Osbourne, Kaypro, Epson and IBM could be read on the C=128.
Nit: The 1541's directory structure lived on track 18, not the C64's.
Track 18 was chosen because it was in the middle. That was the typical way Commodore did it back in the day -- So 4040s, 2031s, 1540s and 1541s had track 18 directories, but 8050s, 8250s, and SFD-1001s had them on track 40.
No idea where the harddrive dirs were, I couldn't afford one.
I think your calculus teacher was probably adjusting your scores by sliding around the marks distribution to achieve a specific mean by the end of the semester.
Then you need to change hosting providers, once more, and finally.
Not providing shell access to a web hosting account is, in my opinion, a crime.
This is why I always deal with mom-n-pop ISPs. "Hey, can I get a shell account on that box?"
Well, plus then I can always say, "If you give me X I'll consult for you on Y"
Even if shell is a little hard to get, there's plenty of places that will let you run PHP programs.
30 seconds of googling turned up phpwebhosting.com, which offers php, mysql, shell, perl, python, ruby-on-rails, a gig of disk and email. For ten bucks a month.
> I've long thought Javascript has been a much maligned language and have sorely felt the
> lack of a good command line Javascript... combined with Tk, well, I look forward to what
> you come up with most eagerly.
You might have to wait a while -- but I'll have something eventually. GUI isn't on the paid-to-develop project plan, but most of the other important bits are. Which is great, I'm getting paid to write software I'd write for free if I could afford to do so. (Shhhh! Don't tell anybody! ;)
> Me too, the last time I did major GUI work was when I wrote Workbench for the Amiga
Did you just say you wrote Workbench for the Amiga? Uhm, listen.. if you're ever in my neighbourhood, ah, dinner's on me.
> But wait, you mention REXX? I wasn't aware that was still in active use, outside the mainframe world..
Those crazy OS/2 guys. You can kill their OS, but not their spirit. :)
I haven't written anything in Object REXX (yes, you heard that right) but it looks like a pretty decent language. One of the guys I work with was heavy in OS/2 until just a couple of years ago.
Me, I haven't actually used REXX since the VM/CMS days. And back then.. I didn't know enough to appreciate it.
Your problem isn't any of the ones you listed. You need to be writing your own back-end applications so you can roll simple (SIMPLE!!!) shit like a guestbook on your own. If you have a year of CS under your belt, you are MORE than qualified to write a guest book.
Doesn't matter what the backend language is, asp.. php... UNIX shell, perl... Control the backend apps, you control the site. Let the hosting provider provider your guestbook? Puh-lease. You'll always be at their mercy because you'd might as well be writing your guestbook-and-similar crap.
Plus you might actually learn some CS problem solving techniques by writing apps. You aren't going to learn CS.squat tweaking HTML and CSS until you're blue in the face.
Maybe y'all could hook up with the engineers down at Queen's, and help them get Clark Hall Pub re-opened?
That place was awesome.
> Maybe it's just me, but I don't like the FCC making rules that cannot
> be read because some company has a copyright on it.
Reminds me of an episode of Numb3rs last season.
(paraphrasing)
FBI Agent: You're under arrest for exporting classified research
Pakistani Scientist: I didn't know my research was restricted! How was I supposed to know??
FBI Agent: The list of classified information is classified
Oh yeah. Get the brown guy!
Actually, not that it wasn't slow, just that it didn't contain certain trivial optimizations. But my assumption is that once it's run a couple of times, the Hotspot code (JIT and adaptive optimizers) will have worked its magic on Rhino, so those optimizations almost certainly become moot over the long term.
I seem to recall it taking longer than that to boot into ProDOS, which IIRC is required for Appleworks.
Those old floppies were not spectacularly fast...
] PR#6
Grriiininininninin groainnnnnginginrrrrinnggngnginn akakakakak
Actually, there are a couple of other advances to hand-coded assembler: reduced code volume, reduced complexity, and reduced feature/scope creep.
Not because hand-coded assembly is faster, mind you... just because it's less typing to write small OSes than big ones.
That said, if i really cared to have a text-editor-capable OS boot quickly, _and_ it needed FAT32.
Hmm.
Is VFAT close enough for ya? Win98 boot disk transmuted onto a USB dongle with the VFAT driver in the config.sys. Boot only to command.com, not the full OS.
It'll probably take longer for your box to POST than to boot that puppy.
Me, I just write shit on my hand with a sharpie.
Yes, but you've missed the key point. (If I understand Rhino correctly, which I think I do)
The javascript is not compiled over-and-over again with the java compiler. Rhino is. Then Rhino emits java byte code which gets the hotspot/jit goodness.
This means that the quality of the optimizations used by the compiler which compiled Rhino is not nearly as relevant as the quality of the bytecode emitted by Rhino, and that the quality of the JIT java bytecode thing probably dominates.
Note, of course, that this is all speculation. I don't use Rhino nor Java.
> There are already Tk bindings for Scheme and Perl as well as Tcl, why not
> implement Javascript/Tk and avoid all the heavy lifting?
In principle? No reason, other that it had never crossed my mind.
Like I said, I'm not a GUI guy. :)
Somehow, I have managed to avoid GUI work for years and years and years and years... I've done GUIs with VB4, lots of web apps, I wrote an X widget once in school... But holy moly that was a long time ago.
On paper your proposal makes a LOT of sense. In fact, the bindings for Lua and REXX will probably provide significant guidance.
Hmm. Thanks!
Suits me fine - Bring it On!
I started a major JavaScript-engine-using project over a year ago.
Boss said: are you sure it will be fast enough?
I said: Between Moore's law and the javascript performance increase that's due, I'm sure it will be.
(Note that at the time ActionMonkey had just been announced, it was a pretty safe bet it woulda arrive)
So far, so good. Another 8 months or so and I should have a product. And it's already in the right performance neighbourhood *without* all this cool new stuff.
> one of the things about the code is that it looks like it is trying to be OO but in straight C
I can totally see how you would come to that conclusion. But, in my opinion that's *not* what it's doing -- it's implementing an OO system (JavaScript) in C. Subtle shade of difference, but an important one. I've written OO code in straight C, and it was far more function pointery. :)
There are couple of things which make writing for jsapi different than your average run-of-the-mill C code.
1. Garbage Collection: If you give memory to the JS engine, you must ensure it will be freed properly... Best analogy I can think of is writing VB4-style C DLLs. If you pass strings back to the non-C language and expect it to manage the string's lifetime, you'd better allocated with the non-C language's allocator.
2. Finalizers: IF you write C classes for JS which absolutely cannot be managed by the garbage collector, you need to write a finalizer for the GC to call
3. What you're writing will usually be a method for a JS object. That's not really relevant to OO-ness from the C point of view.
4. If not a method, it'll probably a getter/setter. Which I consider to be equivalent: prop/method==false dichotomy.
Oh - I just had another analogy -- writing jsapi code for spidermonkey is virtually equivalent to writing JNI code for java. Actually, I'll bet you could make jsapi bindings for cxxwrap or swing. Not that I think that's a good idea.... simply wrapping system libs sucks, I prefer to think them through and create modules with a true javascript-flavour-idiom-blahblahblah.
The other references you've made sound like you've had a look through some of the engine itself, rather than trying to use the API implemented in jsapi.h. I'd... ah, not recommend doing that, unless you're trying to learn "cool tricks". And there are bunch of them in there! But you don't need to read any of them to do productive work.
Also, most of the crazy macros you see coming out of there? You can ignore them and use JS_* functions defined in the API and defined on developer.mozilla.org. MOST of the macro-laced code requires "private knowledge" to prove correct and saves only on function call overhead. Personally, I don't need speed anywhere as bad as I need solid code, so I don't use 'em unless it's impossible not to (rarely if ever) or the profiler tells me I need to (hasn't happened yet).
So, ah. Last two paragraphs in summary: jsapi - good. Internals of spidermonkey - highly optimized at the source-code level. Not good reading, also makes maintenance a challenge.
(for anyone familiar with jsapi reading this -- bz? -- the macro stuff I mentioned, I mean things like the difference between JSVAL_TO_STRING(vp) vs. JS_ValueToString(cx, vp)... They are equivalent in all outside-of-the-interpreter cases, except maybe the branch call back [cx not in rt?], IF vp is a jsstring, ignoring the function call overhead. But if vp is not a jsstring, the behaviour is NOT consistent with what I think non-spidermonkey-maintaining-programmers would expect)
Too bad they didn't copy navigator's DIV.src property.
That would have been even more useful with readyState added.
I used to use it back in the day by ending each dynamically-loaded DIV with a hunk of javascript that triggered a call back.
And DIV.src makes AHAH easier. Well, marginally. Support for HTML OBJECTs would do the trick as well.
I don't know what the current state of the art is, but last I looked Rhino was still the fastest javascript implementation, IF you discounted the JVM start up.
IIRC, Rhino compiles JavaScript into native Java byte code, which then gets the JIT magic sprinkled on it by the JVM pixies.
So the quality of the Java compiler is really not all that relevant, because the code compiled by the compiler only compiles the javascript code once, making the quality of the compiler effectively order(1)... and given sufficiently large N, nobody cares about k.
Now, a javascript->x86 compiler.. that would be interesting. Although javascript->C or javascript->gcc-intermediate would be much nicer, because I don't live in x86-land.
I know nothing of WebKit, so I will not speak of it.
It is currently possible to use SpiderMonkey at the level of ff3 for real work. There's a bit of a learning curve, but it's totally usable. In theory, anything you write for SpiderMonkey-trunk will be usable with the new tracing stuff they've built. That's not in CVS, it's in hg (mercurial), and I'm not sure what state it's in right now. I'm guessing it's probably usable, too. Oh, I think the tracing code also requires a C++ compiler, although I could be wrong.
> I'd like to see a JavaScript engine with pluggable modules (sort of like TCL) and possibly a nice accessible GUI (like TK).
I have been working on something like this, and will get back it to it sooner or later. Probably early november. Unfortunately, great swaths of it is closed (it wraps trade secret libraries), but the basic infrastructure and some of the classes are open. You use it basically like any other UNIX shell interpreter.
When I get back to this project, I plan on more rigorously defining the module loading code to make it easier to extend. Right now, it's pretty easy to compile them in, but there is no good way to load DSOs and so forth. I also want to load JavaScript-language modules more elegantly.
If you want to see my early work -- which is not really all that useful unless you're planning on writing more classes in C to expose whatever it is you want to work with -- go here: http://www.page.ca/~wes/opensource/
As for GUI, I don't really know anything about GUI development, but I'd totally be up for a collaboration if somebody wanted to do simple widgets. I was thinking of ripping apart Dialog for X (nee cdialog) and cloning that functionality someday.
As of right now, I _do_ have a trivial curses interface which can put windows on a terminal, scroll output through them, and so forth. (Not in the link -- insufficient polish). I used it to put together a simple debugging environment where I type JavaScript code and it prints the results in a different window. Basically, like the debug window pair that shipped with QuickBasic 4.5.
Oh -- and the stuff I'm working on is UNIX only. Well, it should run under Cygwin.
I have also played with wsh under Win32. There is a lot of cool stuff you can do, although learning the win32 api appears to be a large and daunting task. I used it to write a simple remote media player for my house, where I could drag a file icon to a JavaScript program on my desktop, which spooled it to a UNIX server in the basement for pickup by a windows box in my living room which in turn would play the content through my home theatre... via another JavaScript program, using the windows media player control.
> implementation issue, and not a JavaScript issue.
This is a common error, which I find myself correcting regularly. It's clearer to me than the average joe, because I write non-browser JavaScript on a regular basis.
> That's why I don't like the idea of having all JavaScript includes behaving as if it's one giant script.
The problem there is that the browser inventors came up with the web-page = program-scope equivalence, with only one program isolation container: iframe. Basically, document is to process as web-page is to operating system.
Furthermore, JavaScript was meant to be used in the browser to only to manipulate the document.. And it doesn't have to be JavaScript. It could just as easily be VBScript...or even lua or python if somebody wrote the bindings and banged it into a browser.
> I'm not sure that this new trend of moving to separate processes will fix anything in these cases, because you can't
> really differentiate between your code and someone else's.
Right. This problem isn't going to be solved without inventing a new container. Or at least making use of the crappy one we have now (iframe).
> Again, browsers have changed a lot over the years, and some methods that worked
> in the past no longer function these days
JavaScript methods, or DOM methods called from JavaScript? There is a huge difference!
JavaScript methods are things like Array.push or String.length. DOM methods are things like document.getElementById. Don't blame the DOM on JavaScript. Just like you shouldn't blame MFC on C++.
> Scripts that were perfectly legal a couple years ago will throw some kind of security exception,
> and that causes the whole site to grind to a halt.
That's because the browsers no longer allow those things. Has nothing to do with the language. I'm sure you'll get the same exceptions calling those same methods from VBScript.
Think of it this way, if root changes a file in your home directory so that you can no longer edit it... is that a problem with bash, or root? Me, I'd grab a pipe, find root, and bash him with it.
I don't mean to come off as a pedant, I'm trying to help people see the world as it really is... so that JavaScript can be taken more seriously, AND so that the people in charge of the browser DOM (etc) design will come up with better application containers and method passing techniques.
(Ever tried to write an AJAX app that spanned domains? It's ridiculously difficult and requires extensive hoop jumping)
Thanks for sharing that comic. It is *so* true.
I recently took over a large body web code from another developer. In order to meet deadlines, I'm working nights and weekends (oh, man, I SO THOUGHT I'd left that behind with my 20s). Needless to say, I'm not happy. To make matters worse, I got pulled off a fun project to work on web shit. With a PHP back end.
So, anyhow.. my kid comes up to me the other day and says, "Boy... you sure swear a lot when you're working!"
And 99% of my swearing is .. you guessed it. WTF?!?!?!?!!!