|
|
Re: my opinion of Javascript
|
Posted: May 11, 2006 10:51 AM
|
|
> Thanks for the links.
>
> /* [JavaScript] was designed with scripting in mind, and
> had an object model slapped onto it for page
> manipulation.
> */
>
> That's it. I had a hard time putting my finger on it
> yesterday, but the reason JavaScript is tied so strongly
> in my mind to DHTML and AJAX is "onmouseover" et. al.
> That is, while the various event handlers are not part of
> f the language per se, because there is no standard
> library they are generally presented as builtins. And of
> course, if the builtins are specialized for page
> presentation ... (yes, I know I'm wrong, but that's where
> my mistake came from).
The only built-ins browser JS specifically for browsers are the window object, some extra methods on the Global object, a few extension methods to the String object, and a few other miscellaneous bits. But as far as JS itself goes, they could be part of a library that gets automatically included and aren't really tied to the language itself.
> /* What you're dealing with in JavaScript is
> Prototype-based OO:
> http://c2.com/cgi/wiki?PrototypeBasedProgramming
> */
I put that link in there because some think that prototype-based OO is inferior or a subset of class-based OO, when all it does is get rid of the dichotomy between objects and classes. The two approaches are isomorphic however.
> /* Support for multi-threading isn't as important as you
> might think,
> */
>
> Well, I do like C++ and Perl. Standard C++ doesn't
> offer multi-threading, and while Perl does, it's
> relatively new. Either way, it's not so important to
> have multi-threading as it is to make sure the
> standard doesn't prevent multi-threading.
Another thing I'd like to disambiguate. Multithreading is just one form of concurrency, and arguably quite a low-level one at that. JS could go down the route of message-passing concurrency like Erlang, occam2, Io, and others, and use Actors, which'd be quite nice. It could include asymmetric coroutines, which'd be sweet (in fact, I believe Brendan Eich is working on this as part of JavaScript 2, not to be confused with the earlier proposal by Waldemar Horwat), or it could add multithreading. A good argument could be made that for the areas JS is targeted, asymmetric coroutines and/or actors are a much better fit with the language than multithreading, and much less of a headache.
> /* [Me] Since the compiler is part of the runtime
> environment,
>
> [response] JS is usually interpreted.
> */
>
> Exactly. I get this way of looking at things from Perl,
> which makes a big deal about whether the compile phase or
> the interpreter is the culprit for limitation X or Y. If
> I'm working in C++, and I want builtin multimethods, I can
> simply standardize on a [a href =
> "http://www.op59.net/cmm/cmm-0.28/readme.html"]compiler
> that offers them[/a].
When you're doing that, you have the advantage that your source doesn't have wide distribution. But, say if you're developing intranet code and the company's standardised on a browser that supports E4X (EMCAScript for XML, Firefox is an example), you'd be able to use extensions that includes.
And I wish more languages supported multimethods too. I'm sick of having to hack them using the Visitor pattern.
> However, that kind of standardization is not possible with
> JavaScript because the compile phase is part of the
> interpreter, a.k.a., the compiler is part of the runtime
> environment.
Yup, but you can say that about almost any interpreted language, save ones with powerful macro systems like Lisp.
> But JavaScript doesn't give me the opportunity to do what
> Nice or Jython do to Java, because even if I have a tool
> to properly tokenize and compile my JavaScript extensions,
> my customers don't (unless I write a browser plug-in).
I'm not entirely sure I'm getting your point here, especially if you bring libraries into it. Say I write something in Jython or Java, build it against Java 5 and give it to somebody still using the Java 1.1 Runtime: it's not guaranteed to work right for them because of library dependencies and other things.
|
|
Previous Topic
