From: Michael G Schwern
Date: 23:15 on 08 Apr 2005
Subject: Javascript: Time Traveller From the Year 1962!
Gee, how original, hating Javascript. But this is a new hate. A fresh
hate. A fundamental hate.
I have to touch Javascript for this project. Sean Burke's written some
mildly positive things about the state of Javascript in 2005 vs 1995 so
I'm going to give it a chance. The project has existing HTML with the
same JS functions copied into the header of each file. Ok, simple enough
refactoring, I'll toss each function into its own .js file. Already
things are looking up!
A lot of pages use most of the functions, so rather than have a ton of
<script src="..."> in each file I'll just write up all.js which does the
moral equivalent of:
include("this.js");
include("that.js");
...
Simple enough, right? Basic 1970s programming technology. Include a file.
So I start looking for such a thing.
And looking.
And looking.
And ask some friends.
Finally I get back this:
function include(jssrc) {
document.write("<script type='text/javascript' src='"+jssrc+"'></script>");
}
include("include2.js");
I have to write my own include function. This include function isn't even
native to Javascript, it relies on the browser DOM. I have to cut & paste
this code into every JS file which wants to include another. I have to
cut & paste code so that I do not have to cut & paste code.
I just double checked, Javascript came about in 1995. Its up to version 1.5.
There's an ISO standard for it. At least three multinational corporations
are actively involved in its development. AND IT HAS NO INCLUDE FUNCTION?!
In related news... Lua. NO NAMESPACES! WHAT THE HELL PEOPLE?! The
tables-as-namespaces makes Perl 5's OO system look clean and well thought
out.
Are the designers of these languages all TIME TRAVELLERS FROM 1962? The
next big thing in language design: variable names with more than eight
characters!
From: David Wheeler Date: 23:45 on 08 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Apr 8, 2005, at 3:15 PM, Michael G Schwern wrote: > I have to write my own include function. This include function isn't > even > native to Javascript, it relies on the browser DOM. I have to cut & > paste > this code into every JS file which wants to include another. I have to > cut & paste code so that I do not have to cut & paste code. My understanding from talking to some JS folks on IRC is that JavaScript was never designed to do I/O. Too much of a security threat in browsers. Of course, this makes it practically useless as a general-use language (maybe one can hack around that in Rhino, but I haven't played with it, yet). http://www.mozilla.org/rhino/ So, without I/O, all you can do is ask the JavaScript host (Mozilla, IE, Safari, whatever) to do it for you. They don't provide a general way, either, so you have to use the DOM to create a new script element. Other than the document.write hack, there's this hack: document.createElement("script"); Uh, then you can set the src and type attributes. But don't expect to use any of that code before the body.onload event fires. The upshot is that I don't think that there can ever be a CJSAN. Pity. > In related news... Lua. NO NAMESPACES! WHAT THE HELL PEOPLE?! The > tables-as-namespaces makes Perl 5's OO system look clean and well > thought > out. At least you can hack around this one by adding properties to functions, including constructors. I did this to create a singleton object in TestBuilder.js; function TestBuilder () { if (!TestBuilder.Test) TestBuilder.Test = this; return TestBuilder.Test; } TestBuilder.Test = TestBuilder.prototype; Cheers, David
From: Michael G Schwern Date: 00:13 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Fri, Apr 08, 2005 at 03:45:07PM -0700, David Wheeler wrote: > My understanding from talking to some JS folks on IRC is that > JavaScript was never designed to do I/O. Too much of a security threat > in browsers. Of course, this makes it practically useless as a > general-use language (maybe one can hack around that in Rhino, but I > haven't played with it, yet). > > http://www.mozilla.org/rhino/ > > So, without I/O, all you can do is ask the JavaScript host (Mozilla, > IE, Safari, whatever) to do it for you. They don't provide a general > way, either, so you have to use the DOM to create a new script element. So I have to write a hack which depends on the JS implementation to work around a blanket security measure. BRILLIANT! Classic, too. > The upshot is that I don't think that there can ever be a CJSAN. Pity. Yes. Alas. :( And now for a generalized and vaguely productive hate: "Early Decisions All Language Designers Will Regret" http://use.perl.org/~schwern/journal/24082 Join in. Its fun!
From: peter (Peter da Silva) Date: 01:35 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > > My understanding from talking to some JS folks on IRC is that > > JavaScript was never designed to do I/O. Too much of a security threat > > in browsers. Of course, this makes it practically useless as a > > general-use language Why? There's no I/O in C and it managed it. > So I have to write a hack which depends on the JS implementation to work > around a blanket security measure. You mean, like C code that depends on UNIX I/O, or stdio?
From: Michael G Schwern Date: 01:59 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Fri, Apr 08, 2005 at 07:35:41PM -0500, Peter da Silva wrote: > > > My understanding from talking to some JS folks on IRC is that > > > JavaScript was never designed to do I/O. Too much of a security threat > > > in browsers. Of course, this makes it practically useless as a > > > general-use language > > Why? There's no I/O in C and it managed it. You'll notice it was one of the first libraries they bolted on. In fact, I've listed "trivializing I/O" as one of the "language design regrets". See also Java. Anyhow, I would not hold up C's I/O system as an example to be followed by HIGH LEVEL LANGUAGES. C, being just a smidge above assembly, is a bit of an exception to the rules.
From: peter (Peter da Silva) Date: 02:32 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > You'll notice it was one of the first libraries they bolted on. Um, no, it wasn't. It wasn't until the '80s before there was a standard I/O library for C. The design of C's file I/O went through at least two major revisions before stdio was selected as the standard. The switch from "-lc" to "-lS" as the default, and then the integration of libC into libc, was a big deal... and if C had started out with an I/O library typical of the '60s it would never have happened... and we'd all be worse off for it. > In fact, > I've listed "trivializing I/O" as one of the "language design regrets". It's not "trivialising I/O", it's "avoiding premature standardization", and it's one of C's strengths... not a weakness.
From: Michael G Schwern Date: 03:07 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Fri, Apr 08, 2005 at 08:32:36PM -0500, Peter da Silva wrote: > > You'll notice it was one of the first libraries they bolted on. > > Um, no, it wasn't. > > It wasn't until the '80s before there was a standard I/O library for C. There were libraries for I/O long before there was a standard library. K&R C had a "standard" I/O library back in 1978 which incorporated most of the functionality various C compiler vendors had already bolted on. People needed I/O and would implement it themselves. Without a standard there was a menagere of competing, incompatible I/O libraries and it took over a decade to clean up the mess... > and if C had started out with an I/O library typical of > the '60s it would never have happened... and we'd all be worse off for it. ...this is not to say it did not eventually all work out for the best. However, that was then. I'm talking about languages written NOW where now == the last ten years or so. > > In fact, > > I've listed "trivializing I/O" as one of the "language design regrets". > > It's not "trivialising I/O", it's "avoiding premature standardization", and > it's one of C's strengths... not a weakness. Like I said, C is the exception. Its just one step above the metal. Its the sort of language you DO write I/O drivers in. I might throw something like Forth into that pile. Javascript or Lua do not go in there. They are modern, high level languages designed to be run in environments where I/O has already been taken care of for them... probably in C. Additionally, C was written in 1972. Back then they were still figuring the basics out. Its 2005 now. We've learned a few things about I/O in the last THIRTY YEARS. Here in the year 2005 we have a pretty good idea about how I/O should work (in part because of the pain C went through). At least enough to know to ignore it at our peril. Java is going through its own I/O pain right now as we watch because they abstracted it into oblivion. C is the exception. Its old. Its very low level. Using it as a guideline for a modern, high level language will only lead to regret.
From: David Champion Date: 04:04 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! * On 2005.04.08, in <20050409020736.GA6183@xxxxxxxx.xxxxxxx.xxx>, * "Michael G Schwern" <schwern@xxxxx.xxx> wrote: > Its the sort of language you DO write I/O drivers in. I might throw > something like Forth into that pile. Javascript or Lua do not go in there. > They are modern, high level languages designed to be run in environments > where I/O has already been taken care of for them... probably in C. These are strange examples, to me, because like Forth, both Javascript and Lua are both designed to be embeddable, and targetted to be embedded. It seems reasonable, to me, to expect the host device/platform (whether this is implemented in hardware or software) to provide the basic I/O facilities. Web browsers indeed do this, via HTML <script> tags and DOM gimmicks and such. You might not like the way the host platform does this, and I wouldn't blame you for a moment, 'cause frankly I hate the way web browsers, hallucinogenically-misbegotten nightmares that they are, do just about everything, but it's not a fault of the language. I never thought I'd be a Javascript apologist. What have I done to deserve this? > Additionally, C was written in 1972. Back then they were still figuring the > basics out. Its 2005 now. We've learned a few things about I/O in the last > THIRTY YEARS. Here in the year 2005 we have a pretty good idea about how > I/O should work (in part because of the pain C went through). At least I dunno. Granted, I've only been doing this stuff for about 20 years, and "seriously" for less than that, but I think your perspective here is a little tinted, or tilted. It's not like 1972 was the dark ages. They'd been compiling things for a couple of decades, and had rapidly-evolving I/O *devices* to deal with -- that surely counts for something in the quality of their understanding of I/O, and I think they knew a few things about I/O then. There certainly have been, shall we say -- and you can shoot me for this when I'm done -- paradigm shifts in the present, but I don't think they happened because we know more about I/O, or because we now know how it ought to be. And I think that in 30 years people are going to think we were completely nuts if they weren't here now to see it happening -- and likely even if they were. But right, you're not talking about C.
From: peter (Peter da Silva) Date: 13:28 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > I never thought I'd be a Javascript apologist. What have I done to > deserve this? You had the poor taste to be smart enough to tell that JS is rather a nice language design that's unfortunately hobbled by its association with web browsers. I was astonished when I reached that concludion myself, since I was inclined to think the worst of a language that (as it turned out, through no fault of its own) had caused me so much trouble over the years. Makes me hate the twisty structure of the browsers all the more for what they have done in hobbling Javascript.
From: peter (Peter da Silva) Date: 04:09 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > There were libraries for I/O long before there was a standard library. Yeh, and if you'd used the v6 libc you'd know why it was a good idea that they didn't rush out and define I/O for C. To do the equivalent of sprintf you opened a pipe, printf-ed to it, and read it into a string. > K&R C had a "standard" I/O library back in 1978 which incorporated most of > the functionality various C compiler vendors had already bolted on. That's "-lS". I used it. Compiler "vendors"? No such thing in 1978. > People > needed I/O and would implement it themselves. Without a standard there > was a menagere of competing, incompatible I/O libraries and it took over a > decade to clean up the mess... Um, no, there wasn't. Unless you count Idris, but they only did it differently because they were trying to avoid stepping on AT&T's copyright on the UNIX progranmmer's manual. Back in the '70s there was only one C compiler, and it was described in the UNIX programmer's manual. The paucity of implementations was such that Ratfor was actually a viable alternative. > > and if C had started out with an I/O library typical of > > the '60s it would never have happened... and we'd all be worse off for it. > ...this is not to say it did not eventually all work out for the best. It worked out quite well all along. There were steady improvements all through the '70s. > However, that was then. I'm talking about languages written NOW where now > == the last ten years or so. And I'm saying that languages written NOW are running into a whole new iteration of the same mess that C was faced with. The mess of I/O standards, now including window systems and toolkits, is exactly the same kind of mess that I/O was in in the '60s. > > > In fact, > > > I've listed "trivializing I/O" as one of the "language design regrets". > > It's not "trivialising I/O", it's "avoiding premature standardization", and > > it's one of C's strengths... not a weakness. > Like I said, C is the exception. Its just one step above the metal. The metal has moved. > Its the sort of language you DO write I/O drivers in. I might throw > something like Forth into that pile. Javascript or Lua do not go in there. Javascript is the Forth of this decade. It operates in environments where there is no C-like I/O Putting C I/O into Javascript is about as important as putting Fortran I/O into C would have been. > They are modern, high level languages designed to be run in environments > where I/O has already been taken care of for them... probably in C. Yeh, and they're run in environments where C I/O is inappropriate. > Additionally, C was written in 1972. Back then they were still figuring the > basics out. Its 2005 now. And we're still figuring the basics out. > We've learned a few things about I/O in the last > THIRTY YEARS. Here in the year 2005 we have a pretty good idea about how > I/O should work (in part because of the pain C went through). And how should I/O in a web browser work? How should I/O in a GUI work? How about sockets? You can't write() to a socket in Windows. > At least > enough to know to ignore it at our peril. Java is going through its own > I/O pain right now as we watch because they abstracted it into oblivion. Java is fucked in so many ways that even if they'd standardised on stdio they'd still be in pain. > C is the exception. Its old. Its very low level. Using it as a guideline > for a modern, high level language will only lead to regret. That's why I'm suggesting that it's a bad idea to try and treat the I/O objects that a GUI, web, or database environment has to operate on using C as a model.
From: David Wheeler Date: 05:05 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Apr 8, 2005, at 8:09 PM, Peter da Silva wrote: > And how should I/O in a web browser work? How should I/O in a GUI work? > How about sockets? You can't write() to a socket in Windows. Oh for fuck's sake, all I want to be able to do is load other .js files so that I can modularize things and appropriately manage dependencies. I can work around all the other crap. And I want to be able to load them via URIs--just as I can currently load XML files over HTTP in JavaScript! Is that so much to ask? The rest of this discussion is just philosophy. It doesn't get me any closer to getting my work done. David
From: peter (Peter da Silva) Date: 13:45 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > Oh for fuck's sake, all I want to be able to do is load other .js files > so that I can modularize things and appropriately manage dependencies. That's not something I would even expect to be defined in the language, any more than "#include <stdio.h>" is defined in C. Javascript is not inherently a scripting-oriented language with "eval" baked into its bones the way Forth or Lisp or Tcl is, or even an intermediate language like Perlm so embedding filenames and URIs into executable code is not a natural way to do things. Yes, it has an eval, but the languge is not inherently designed to be composed and evalled, the way Lisp- and Forth- family languages are. It's even worse at that than SQL is. I would expect you'd do something like this: <script source="includefile.js"></> <script source="anotherinclude.js"></> <script source="code.js"></> And use the module management that's built up around JS, in this case at the HTTP/HTML level, take care of it. The real problem here is that HTML, which is where the stuff you're trying to do lives, doesn't have <include source="something.html"/> So you need server-side scripting to suck in the above series of refs. But you DO have that, don't you? If not, then hate the webserver and then build your webpages outside of it.
From: Michael G Schwern
Date: 23:49 on 09 Apr 2005
Subject: Re: Javascript: Time Traveller From the Year 1962!
On Sat, Apr 09, 2005 at 07:45:36AM -0500, Peter da Silva wrote:
> > Oh for fuck's sake, all I want to be able to do is load other .js files
> > so that I can modularize things and appropriately manage dependencies.
>
> That's not something I would even expect to be defined in the language,
> any more than "#include <stdio.h>" is defined in C.
<snip>
> I would expect you'd do something like this:
>
> <script source="includefile.js"></>
> <script source="anotherinclude.js"></>
> <script source="code.js"></>
Ahh, the fundamental difference here is that the include in C goes into the
source code but the include in JS goes into the thing USING the source code.
Major difference.
Let's say we have a library Foo which depends on libraries Lib1 and Lib2. In
most programming languages it would be written like this.
# The library Foo
include Lib1;
include Lib2;
function Foo {
... uses stuff from Lib1 and Lib2 ...
}
# The program which uses Foo
include Foo;
Foo(...);
Foo's dependencies on Lib1 and Lib2 are resolved inside Foo encapsulating
it from the user.
But since Javascript has no include() of its own it falls upon the *user of
the code* to resolve the dependencies. The code is written like this:
# The library Foo
function Foo {
... uses stuff from Lib1 and Lib2 ...
}
# The program which uses Foo
include Lib1;
include Lib2;
include Foo;
Foo(...);
Now internal information about Foo has leaked out into the user world.
Encapsuation is violated. If I want to change Foo's internal dependencies
I must now find all the code which uses Foo and change it.
This is Bad. This discourages modular programming. This leaves everyone
to reimplement basic functionality over and over again. That's the hate
I'm talking about. Anything that involves putting the include functionality
into the web page, be it <script> or SSI or whatever, has that hate.
C gets away with pasting together its source code because it is a static
language with distinct compile, link and run stages (even still dynamic
loading was bolted on). Javascript is not. Its an interpreted/JIT language
which does not have a build step in which to run a preprocessor. You write
the code, it runs. Adding a build step for a preprocessor would be clunky
and artificial.
> I can't conceptually see a better option, really, than something like:
>
> document.write("<script source=\"include.js\"></script>");
I can. The above idiom relies on the existence of a DOM beyond the pure
EMCAscript language. The DOM defines hundreds of built in functions.
Well for god's sake, could they stop adding new ways to make things rotate
for a second and add one useful function to the language?!
function include(source) {
document.write("<script source\"" + source + "\"></script>");
}
At least then I don't have to cut & paste that code into every .js file
I write. Sheesh.
From: peter (Peter da Silva)
Date: 00:09 on 10 Apr 2005
Subject: Re: Javascript: Time Traveller From the Year 1962!
> Ahh, the fundamental difference here is that the include in C goes into the
> source code but the include in JS goes into the thing USING the source code.
That's because in "C" it's preprocessed before the compiler sees it.
Run your javascript through the preprocessor.
If that's too hard, then hide it, make it automatic, like it is in C. It's
a function of the hosting environment, not the language.
> Well for god's sake, could they stop adding new ways to make things rotate
> for a second and add one useful function to the language?!
> function include(source) {
> document.write("<script source\"" + source + "\"></script>");
> }
Because this is done at EXECUTE time, and prevents you from writing a JS
compiler EVEN IF YOU WANTED TO.
This stuff has to exist OUTSIDE the eval loop. Putting it IN the eval loop
would prevent Javascript from being usable as anything but a scripting
language, ever, and it's too good for that.
From: Michael G Schwern Date: 00:50 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Sat, Apr 09, 2005 at 06:09:06PM -0500, Peter da Silva wrote: > > Ahh, the fundamental difference here is that the include in C goes into the > > source code but the include in JS goes into the thing USING the source code. > > That's because in "C" it's preprocessed before the compiler sees it. > > Run your javascript through the preprocessor. > > If that's too hard, then hide it, make it automatic, like it is in C. It's > a function of the hosting environment, not the language. "Adding a build step for a preprocessor would be clunky and artificial." ie. I can do it, but it sucks and I hate it. (See? Hate. Thus on-topic. :) Or maybe I'm not understanding how it would remain a single build/run step instead of a two step 1. build 2. run as C requires. > Because this is done at EXECUTE time, and prevents you from writing a JS > compiler EVEN IF YOU WANTED TO. > > This stuff has to exist OUTSIDE the eval loop. Putting it IN the eval loop > would prevent Javascript from being usable as anything but a scripting > language, ever, and it's too good for that. Assuming by "compiler" you mean "translate to machine-code"... The compiler can do a pre-processing pass replacing uses of include() with the appropriate pasted code. It then compiles the result. PS Somebody earlier had said that JavaScript does not have I/O. http://www.njs-javascript.org/manual/js_2.html#SEC50 http://www.njs-javascript.org/manual/js_2.html#SEC51 Apparently its a Netscape feature that didn't make it into EMCAscript. I noticed it because while looking for a Javascript compiler I found this blurb about a JavaScript compiler and wondered "well how is it writing a file?" http://www.njs-javascript.org/manual/js_9.html "The JavaScript compiler is implemented in the JavaScript language... The compiler compiles JavaScript source code to byte-code and it returns a fixed byte-code file as the result." This compiler goes to byte-code not machine code and its implementation of JavaScript does include an eval() extension. http://www.njs-javascript.org/manual/js_2.html#SEC62
From: peter (Peter da Silva) Date: 01:16 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > "Adding a build step for a preprocessor would be clunky and artificial." "If that's too hard, then hide it, make it automatic, like it is in C." > Or maybe I'm not understanding how it would remain a single build/run step When you build a new version of the website, you add this step after you check the pages out of CVS. If your code is just randomly edited raw HTML, then server-side includes. > > This stuff has to exist OUTSIDE the eval loop. Putting it IN the eval loop > > would prevent Javascript from being usable as anything but a scripting > > language, ever, and it's too good for that. > Assuming by "compiler" you mean "translate to machine-code"... By "compiler" I mean "anything that creates a non-volatile parsed form of the code, this avoiding a trip through eval next time it's run." > The compiler can do a pre-processing pass replacing uses of include() with Not unless "include" is defined as part of the language, because I may be referring to "myobject.include" which has nothing to do with including source code. > PS Somebody earlier had said that JavaScript does not have I/O. > http://www.njs-javascript.org/manual/js_2.html#SEC50 > http://www.njs-javascript.org/manual/js_2.html#SEC51 > Apparently its a Netscape feature that didn't make it into EMCAscript. Good, this is a low-level OS-specific library. This isn't <stdio.h>, this is <unistd.h>.
From: Michael G Schwern Date: 01:51 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Sat, Apr 09, 2005 at 07:16:28PM -0500, Peter da Silva wrote: > > The compiler can do a pre-processing pass replacing uses of include() with > > Not unless "include" is defined as part of the language, because I may be > referring to "myobject.include" which has nothing to do with including source > code. Yes, include() would have to be part of the standard. The whole point.
From: peter (Peter da Silva) Date: 02:05 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > > Not unless "include" is defined as part of the language, because I may be > > referring to "myobject.include" which has nothing to do with including source > > code. > Yes, include() would have to be part of the standard. The whole point. That means you have to define the hosted environment in FAR more detail than is appropriate for an embedded language, AND in more detail than is justified at this point. There's no guarantee that a Javascript implementation even has a file system available to it through ANY path. The include you're talking about, that belongs in the hosting environment, not the language. I'll agree that the hosting environment sucks, but I've already made that point, but it's NOT something that belongs in the language.
From: Michael G Schwern Date: 04:18 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Sat, Apr 09, 2005 at 08:05:00PM -0500, Peter da Silva wrote: > > Yes, include() would have to be part of the standard. The whole point. > > That means you have to define the hosted environment in FAR more detail than > is appropriate for an embedded language, AND in more detail than is justified > at this point. There's no guarantee that a Javascript implementation even > has a file system available to it through ANY path. > > The include you're talking about, that belongs in the hosting environment, > not the language. I'll agree that the hosting environment sucks, but I've > already made that point, but it's NOT something that belongs in the language. I think we're caught in an endless argument here due to the fact that we're using "language" differently. You mean the grammar stripped of all libraries and auxillary widgets. I'm including the libraries and all the auxillary widgets and in Javascript's case, the web widgets. Let's move away from that for a moment because I'm sick of this argument. The particular JavaScript "hosting environment" which I care about, which is to say a web browser, does have a standard for JavaScript already. They've already defined hundreds of functions. They already have a way to load and eval JavaScript files. So take that LAST STEP and add an import() method to the "hosting environment". That's all I'm saying. I don't give a crap about the core language, I'm not an embedded systems programmer, don't know a damn thing about it and can't comment on it. All I know is high level languages. PS What is the term for "the Javascript language plus all the crap needed to use it in a web page?" I thought that was referred to as the DOM. DHMTL maybe?
From: peter (Peter da Silva) Date: 04:34 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > I think we're caught in an endless argument here due to the fact that we're > using "language" differently. You mean the grammar stripped of all libraries > and auxillary widgets. I'm including the libraries and all the auxillary > widgets and in Javascript's case, the web widgets. That's not part of the language in any sense. I have a Javascript interpreter right here that doesn't have any of that. > The particular JavaScript "hosting environment" which I care about, which is > to say a web browser, does have a standard for JavaScript already. They've > already defined hundreds of functions. They already have a way to load and > eval JavaScript files. So take that LAST STEP and add an import() method > to the "hosting environment". That's all I'm saying. And what I'm saying is that's the wrong place to add it, because it requires doing too much at runtime and making it REALLY portable, the way you want, requires all kinds of shenanigans that will bog you down in figuring out where the libraries for *this* server are... and doing server-side includes to load the site-dependent variables that the runtime will need to figure out where to load the stuff. The right way is to define an include *directive* at the *ML level that happens before Javascript ever sees it. If you're adding stuff to the thing anyway, do it right. > I don't give a crap about the core language, This side-thread started out when you sent me to a web page ranting about the language. I've already said, twice now, that the part you're *really* complaining about really does suck... but it's NOT Javascript's fault: Javascript itself is probably the best C-inspired object-oriented language out there, and it's getting a bum rap from the browser environment.
From: David Champion Date: 08:36 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! * On 2005.04.09, in <20050410031801.GB3231@xxxxxxxx.xxxxxxx.xxx>, * "Michael G Schwern" <schwern@xxxxx.xxx> wrote: > > I think we're caught in an endless argument here due to the fact that we're > using "language" differently. You mean the grammar stripped of all libraries > and auxillary widgets. I'm including the libraries and all the auxillary > widgets and in Javascript's case, the web widgets. Let's move away > from that for a moment because I'm sick of this argument. What you describe is an implementation of a language. > The particular JavaScript "hosting environment" which I care about, which is > to say a web browser, does have a standard for JavaScript already. They've They have a standard binding betweeen JavaScript, a language, and the native DOM. That's what ECMAScript provides. > already defined hundreds of functions. They already have a way to load and > eval JavaScript files. So take that LAST STEP and add an import() method > to the "hosting environment". That's all I'm saying. The hosting environment needs to do that. > I don't give a crap about the core language, I'm not an embedded systems > programmer, don't know a damn thing about it and can't comment on it. All > I know is high level languages. You're an embedded systems programmer the moment you start developing in JavaScript for deployment in web browsers, because web browsers embed JavaScript. So... humbly I suggest that you should consider giving a crap. > PS What is the term for "the Javascript language plus all the crap needed > to use it in a web page?" I thought that was referred to as the DOM. DHMTL > maybe? DHTML, perhaps, if there is such a term, though as a purist I'd tend to favor "Javascript hosted by a web browser". As I understand it -- and note that I hate the web, and don't exactly keep up -- the DOM refers to the structure for representing and manipulating the document elements within the browser (the "hosting environment"). DHTML specifies the relationship between HTML and the DOM (how parsed HTML maps into the DOM) and how they may interact programmatically or through the user event loop -- which is by way of ECMA bindings when the scripting language is JavaScript.
From: David Wheeler Date: 19:43 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Apr 9, 2005, at 8:18 PM, Michael G Schwern wrote: > The particular JavaScript "hosting environment" which I care about, > which is > to say a web browser, does have a standard for JavaScript already. > They've > already defined hundreds of functions. They already have a way to > load and > eval JavaScript files. So take that LAST STEP and add an import() > method > to the "hosting environment". That's all I'm saying. Amen. D
From: Michael G Schwern Date: 01:19 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Sat, Apr 09, 2005 at 04:50:10PM -0700, Michael G Schwern wrote: > > That's because in "C" it's preprocessed before the compiler sees it. > > > > Run your javascript through the preprocessor. > > > > If that's too hard, then hide it, make it automatic, like it is in C. It's > > a function of the hosting environment, not the language. Something I forgot... preprocessing IS part of the C language. Ok, let's split hairs here. Preprocessing is part of the C *standard* which is much more useful to talk about than the C *language* which does not even include a way to print. This exposes why my using a pre-processor does not solve the problem of a language standard not having an include method, be it at run-time via eval as in dynamic languages or at compile-time via a pre-processor in C. Its part of the C standard. It is not part of the Javascript standard. This means that *locally* I can slap together whatever pre-processor include system I want for Javascript and use it but I cannot ship code which uses it because it won't run anywhere else. Its not standardized. I have to ship the post-processed spaghetti. And if anyone's ever looked at post-processed C code from even a simple program... eww. Not getting any useful patches against that. You can't ship nice, neat, reusable modules. You can't have a CJSAN. Modular programming is crippled. How far would C have gotten if #include was not standardized? Not very far. A defacto standard would have emerged PDQ.
From: peter (Peter da Silva) Date: 02:01 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > Something I forgot... preprocessing IS part of the C language. The C language that didn't have I/O, well, you know, it didn't have a standard either, and there were two preprocessors (CPP and M4). Speaking of I/O... The "non-hosted" standard for embedded C, which more closely matches the JS environment, has no I/O either. Languages designed for embedding are *different*. And, no, Perl isn't one of them. > This means that *locally* I can slap together whatever pre-processor include > system I want for Javascript and use it but I cannot ship code which uses it > because it won't run anywhere else. Your Javascript code won't run anywhere else anyway, because you need a lot more infrastructure than in "include" statement to support libraries. > Its not standardized. I have to ship > the post-processed spaghetti. And if anyone's ever looked at post-processed > C code from even a simple program... eww. An include processor is NOT the same as cpp. It can be as simple as an awk script. I wrote the second version of the INSMOD processor at Ferranti in Fortran. > Not getting any useful patches > against that. You can't ship nice, neat, reusable modules. You can't have > a CJSAN. Modular programming is crippled. The kind of "modular programming" you're talking about depends on a hosting environment that supports it, and Javascript doesn't have that by itself, and *can't* have that in a portable fashion by itself, because it's different for every server and every site. Your options are: 1. Put all the include files in the same directory. No CJSAN there. 2. Dictate the structure of the website. 3. Ship a build script that does the work you need, with Makefile variables (or equivalent) that specify the structure... and once you've done that you can ship the preprocessor as well. > How far would C have gotten if #include was not standardized? #include wasn't standardised. On VMS it was "#include stdio". The Allman compiler built CPP into pass 1. Exec/8 file names couldn't use ".", that was used to separate the file (directory) from the element (file). > A defacto standard would have emerged PDQ. I was #ifdefing around VMS include syntax in 1984. You'd be AMAZED how hateful things have been in the past.
From: Michael G Schwern
Date: 02:02 on 10 Apr 2005
Subject: Re: Javascript: Time Traveller From the Year 1962!
On Sat, Apr 09, 2005 at 06:09:06PM -0500, Peter da Silva wrote:
> > Well for god's sake, could they stop adding new ways to make things rotate
> > for a second and add one useful function to the language?!
>
> > function include(source) {
> > document.write("<script source\"" + source + "\"></script>");
> > }
>
> Because this is done at EXECUTE time, and prevents you from writing a JS
> compiler EVEN IF YOU WANTED TO.
I was thinking about this some more and it occured to me.. since the above is
an extension to the DOM, not the core language, it assumes its going to be
running inside a web browser: a trusted environment on an unknown platform.
You don't want to be shipping machine code. Best you can do is byte-code
to be run through a VM. The byte-code compiler can spot the include()s and
compile them as well. You would have to include the limitation that
include() only takes a static string, not a variable, but that's ok by me.
From: peter (Peter da Silva) Date: 02:13 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > I was thinking about this some more and it occured to me.. since the above is > an extension to the DOM, not the core language, Bingo. It's a function of the hosting environment, not the language. > it assumes its going to be > running inside a web browser: a trusted environment on an unknown platform. An untrusted environment on an unknown platform. But if it's server-side Javascript, it's a different environment, and if it's Javascript run from a commandline it's in yet another environment, and if it's compiled Javascript it's something else altogether. You were saying that Javascript won't ever be a general purpose language without this. I'm saying it won't ever be one if you hardcode assumptions about the hosting environment in the language. > You don't want to be shipping machine code. There's no difference between machine code and bytecode here. > Best you can do is byte-code > to be run through a VM. The byte-code compiler can spot the include()s and > compile them as well. So can the machine code compiler. No difference. > You would have to include the limitation that > include() only takes a static string, not a variable, but that's ok by me. But that would completely block any use of include() in portable code that isn't bound to the file layout on the webserver, which voids your objection to using SSI or preprocessors or other server-side techniques, since you'll have to run at least one perprocessing pass over the code to configure it for the target system.
From: Geoff Richards Date: 01:47 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Sat, Apr 09, 2005 at 03:49:12PM -0700, Michael G Schwern wrote: > ... > > This is Bad. This discourages modular programming. This leaves everyone > to reimplement basic functionality over and over again. That's the hate > I'm talking about. Anything that involves putting the include functionality > into the web page, be it <script> or SSI or whatever, has that hate. I was actually suggesting putting the SSI in the JavaScript source files. Then it would be just like having a real JS 'include' directive, except with a rather odd syntax. The only problem I can see is you'd have to update the modification time on the 'main' JS file whenver one of the included ones was modified, to get cached versions updated.
From: Michael G Schwern Date: 01:54 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Sun, Apr 10, 2005 at 01:47:16AM +0100, Geoff Richards wrote: > > This is Bad. This discourages modular programming. This leaves everyone > > to reimplement basic functionality over and over again. That's the hate > > I'm talking about. Anything that involves putting the include functionality > > into the web page, be it <script> or SSI or whatever, has that hate. > > I was actually suggesting putting the SSI in the JavaScript source > files. Then it would be just like having a real JS 'include' directive, > except with a rather odd syntax. Clever. I might make use of that for myself, thanks. But still non-standard and thus unshippable. :( > The only problem I can see is you'd > have to update the modification time on the 'main' JS file whenver one > of the included ones was modified, to get cached versions updated. Shouldn't SSI trigger a cache flush based on the mod time of the files being included rather than just the file doing the including?
From: peter (Peter da Silva) Date: 02:06 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > Shouldn't SSI trigger a cache flush based on the mod time of the files being > included rather than just the file doing the including? The cache isn't in the server. The client doesn't know about the include.
From: Abigail Date: 00:57 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! --0ntfKIWw70PvrIHh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 09, 2005 at 07:45:36AM -0500, Peter da Silva wrote: >=20 > The real problem here is that HTML, which is where the stuff you're trying > to do lives, doesn't have >=20 > <include source=3D"something.html"/> Oh, but it has. SGML has it, and hence, HTML has it. However, I've yet to encounter an browser that comes close to actually being able to parse HTML.=20 Heck, after 15 years, most browser are still unable to parse an HTML comment, so it's not surprising they are totally oblivious about any SGML construct that's more advanced. It's so much more satisfying to implement BLINK or MARQUE.=20 Abigail --0ntfKIWw70PvrIHh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCWGvgBOh7Ggo6rasRAvR6AJ9Z+iGDPm6Lqs3y5blQp1FFThg1LQCeI55A udJGnSsdYQiYjTD8bFIsvI8= =KoXQ -----END PGP SIGNATURE----- --0ntfKIWw70PvrIHh--
From: peter (Peter da Silva) Date: 13:23 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > Oh, but it has. SGML has it, and hence, HTML has it. However, I've yet > to encounter an browser that comes close to actually being able to parse > HTML. Oooh, yes, a different kind of hating altogether. A tired, dull hate, rather like the hate one has for everyone else on the road when one is stuck in traffic... and, alas, just as impractical.
From: Geoff Richards
Date: 18:08 on 09 Apr 2005
Subject: Re: Javascript: Time Traveller From the Year 1962!
On Fri, Apr 08, 2005 at 09:05:16PM -0700, David Wheeler wrote:
>
> Oh for fuck's sake, all I want to be able to do is load other .js files
> so that I can modularize things and appropriately manage dependencies.
> ...
If you fiddle with Apache a bit, then this might work:
<!--#include virtual="util.js" -->
I know, I'm sick.
From: David Wheeler Date: 18:27 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Apr 9, 2005, at 10:08 AM, Geoff Richards wrote: > I know, I'm sick. You make me look healthy! D
From: Chris Winters Date: 01:11 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! * David Wheeler (david@xxxxxxxxxx.xxx) [050408 18:55]: > My understanding from talking to some JS folks on IRC is that > JavaScript was never designed to do I/O. Too much of a security threat > in browsers. Of course, this makes it practically useless as a > general-use language (maybe one can hack around that in Rhino, but I > haven't played with it, yet). > > http://www.mozilla.org/rhino/ I've played with this quite a bit. It's pretty nifty, and it does have an include: load( 'foo.js' ); Exposing Java classes via JavaScript is pretty simple as well and you can do all your IO that way pretty easily. And creating JavaScript objects that implement Java interfaces is pretty easy too. (Examples on request...) Chris
From: David Wheeler Date: 01:20 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Apr 8, 2005, at 5:11 PM, Chris Winters wrote: > I've played with this quite a bit. It's pretty nifty, and it does have > an include: > > load( 'foo.js' ); Somebody please add this to the main language in a way that supports URLs, too! Thank you, that is all. David
From: peter (Peter da Silva) Date: 01:46 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! Namespaces? Uh, Javascript is a template-based OO language. Every object is a namespace!
From: Michael G Schwern Date: 02:01 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Fri, Apr 08, 2005 at 07:46:51PM -0500, Peter da Silva wrote: > Namespaces? > > Uh, Javascript is a template-based OO language. > > Every object is a namespace! Oh yeah. But without a way to load other files its rendered largely useless. :(
From: peter (Peter da Silva)
Date: 14:01 on 09 Apr 2005
Subject: Re: Javascript: Time Traveller From the Year 1962!
> > Namespaces?
> > Uh, Javascript is a template-based OO language.
> > Every object is a namespace!
> Oh yeah. But without a way to load other files its rendered largely useless.
Oh, geeze, you want to shove a bunch of eval into the core of JS as well,
like some kind of sausage stuffed with boar nostril hairs and floor sweepings?
If you want a language built around eval, use a Lisp-derived language like
Tcl. It's a great model, I enjoy it a lot, but it's not what Javascript is
about. You need to embed your JS in that kind of framework, not a browser.
Let's say JS had a "script" object, and
script.include("URI");
Now when you're running JS as a command line scripting language, what do you
do? Well, you start writing code like:
script.include("file:///.../foo.js"):
And now you're going to have to eval that at runtime (no precompiled code
for us). What you really want here is:
#include "foo.js"
But that doesn't make sense in a browser, whereas the <script source=...>
stuff does. Does it suck that JS is bound to the browser model? Why yes, I
already noted that myself. But it's not something you can fix at the
language level until you're working with a non-browser environment.
So either you drag the whole browser environment, INCLUDING the HTML, into
the command line, or else you jettison the whole browser-based file framework
and start over with something else that actually makes sense.
I can't conceptually see a better option, really, than something like:
document.write("<script source=\"include.js\"></script>");
Which brings us full circle.
From: peter (Peter da Silva) Date: 13:30 on 09 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > > http://www.mozilla.org/rhino/ What has Javascript done to deserve being embedded in such hateful software? First the browser, now the dastardly Java itself...
From: Michael G Schwern
Date: 09:50 on 10 Apr 2005
Subject: Re: Javascript: Time Traveller From the Year 1962!
Last word on all this Javascript crap.
Sean Burke came up with something interesting, the upshot being that
you write this in your HTML...
<script type="text/javascript" src="js/bootstrap.js"></script>
<script type="text/javascript" src="js/hello.js"></script>
And then you can use bootstrap() inside your code.
# hello.js
bootstrap("js/greeter.js");
function sayhello () {
greet();
}
# greeter.js
function greet () {
alert("Hello world!");
return;
}
You can poke at it here.
http://interglacial.com/temp/Bootstrapping/
Here's what Sean said on IRC while puting it together.
Apr 08 21:31:17 <TorgoX> also, if I didn't have to care about error handl
ing or gracefully dealing with shitty old browsers, I could make this a one-line
r. But as it is, it's about 25 lines or something...
Apr 08 21:32:21 <TorgoX> I did have some clever idea about a workaround f
or the lack of an @INC -- basically involving a "bundler" program that figures o
ut what-all libary functions get used, and does a sultry dance of symlink resolu
tion or something.
Apr 08 21:47:19 <TorgoX> Schwern -- I think my current modus with JavaScr
ipt is that I'm designing semi-general-purpose things, like a bootstrapper that
I can live with, without totally making my head explode by trying to catch every
case ever.
Final hate: JavaScript's been around for TEN YEARS and nobody's figured
this out yet??
From: peter (Peter da Silva) Date: 13:28 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > Final hate: JavaScript's been around for TEN YEARS and nobody's figured > this out yet?? People have figured out that by the time you care about this you're pretty much beyond "edit raw HTML files in the production system" and you've got a whole build and ship process going. Why *that* hasn't been better developed and standardised is another source of hate.
From: David Wheeler Date: 19:50 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Apr 10, 2005, at 5:28 AM, Peter da Silva wrote: > People have figured out that by the time you care about this you're > pretty > much beyond "edit raw HTML files in the production system" and you've > got > a whole build and ship process going. > > Why *that* hasn't been better developed and standardised is another > source > of hate. And that, to my mind, is the underlying issue--and explains why there really can't ever be a CJSAN... Regards, David
From: peter (Peter da Silva) Date: 21:05 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! > And that, to my mind, is the underlying issue--and explains why there > really can't ever be a CJSAN... Sure there can. Just not for browser applets.
From: David Wheeler Date: 19:49 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! On Apr 10, 2005, at 1:50 AM, Michael G Schwern wrote: > You can poke at it here. > http://interglacial.com/temp/Bootstrapping/ This is just the approach of creating the appropriate script element. I'm glad that Sean has created one that's reasonably portable, and I'll likely use it in my code, but it would be nice to have something general-purpose for this sort of thing that ships with browsers... Cheers, David
From: David Champion Date: 23:02 on 10 Apr 2005 Subject: Re: Javascript: Time Traveller From the Year 1962! * On 2005.04.10, in <20050410085016.GC4918@xxxxxxxx.xxxxxxx.xxx>, * "Michael G Schwern" <schwern@xxxxx.xxx> wrote: > Last word on all this Javascript crap. > > Sean Burke came up with something interesting, the upshot being that > you write this in your HTML... > > <script type="text/javascript" src="js/bootstrap.js"></script> > <script type="text/javascript" src="js/hello.js"></script> > > And then you can use bootstrap() inside your code. > ... > Final hate: JavaScript's been around for TEN YEARS and nobody's figured > this out yet?? Sure they have. I figured that out on my first JavaScript application, because I immediately found both the browsers I was working with to have horrible implementations for practical development. I've read books that use that, to some extent. This trick provides you a way or reusing some functions and/or data, but it's not a language intrinsic, it's a way of working around browser limitations within the means that the browser provides you for loading code into the parser. I don't know how one would find this kind of trick if one needed to know about it, though. Most people developing JavaScript with browsers just couldn't care less if it doesn't make users' mouse pointers flutterier or their status bars tackier or their right mouse buttons less functional or whatever. -- To get back onto the topic of software hate. Off software hate again: I've yet to find a JS resource in paper or electronic form that doesn't target that kind of inane crap, rather than general-purpose development in a browser context. Admittedly I spend little enough time doing this that I haven't tried to throw much money at the problem, but the money I have thrown has gone pretty much entirely toward telling me how, when doing such inane crap, to detect and play nicely with both Internet Explorer and Netscape, neither of which I really could give a dead goldfish for.
Generated at 10:26 on 16 Apr 2008 by mariachi