The Artima Developer Community
Sponsored Link

Weblogs Forum
Another Notch for JavaScript: HD DVD

10 replies on 1 page. Most recent reply: May 12, 2006 9:50 AM by Max Lybbert

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 10 replies on 1 page
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Another Notch for JavaScript: HD DVD (View in Weblogs)
Posted: May 9, 2006 9:47 AM
Reply to this message Reply
Summary
HD DVD not only offers high-definition video playback, it also uses JavaScript and XML for authoring menus, interactive content, persistant storage, and network connectivity.
Advertisement
In my new role at Microsoft, one of the projects I have been involved in is documenting authoring HD DVD interactive content using XML and JavaScript (ECMAScript Compact Profile 3rd Edition to be precise), and documenting the new free HD DVD simulation and validation tools that are now provided by Microsoft ( http://www.microsoft.com/windows/windowsmedia/forpros/hddvd/default.aspx ). The potential for the HD DVD is pretty exciting when you consider that HD DVD players will eventually all support internet connectivity and persistant storage.

So where is this all leading I wonder? Are HD DVD players going to replace PC's in people's homes? Maybe we will eventually simply place a central server in a basement closet next to the water heater, and everything else will be a terminal with wireless connections?


Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Where *is* this headed? Posted: May 9, 2006 11:17 AM
Reply to this message Reply
Amazon's said that when they started, they were doing things a Bachelor's in Computer Science didn't cover. Ditto for Google, and ditto for game development.

As we get computers in stranger places, I wonder if we'll ever take another look at Computer Science programs, and decide that maybe we should break them up into different branches of Computer Science, or teach more than compilers and operating systems (and maybe networking if you're lucky).

I'm kind of suprised that JavaScript can be used outside of web pages. OTOH, DVD menus are very similar to content-free web pages, so it's really not that big a difference.

However, if keeping up has been hard before, I wonder what it'll look like in a few years.

Keith Gaughan

Posts: 17
Nickname: kgaughan
Registered: Feb, 2003

Re: Where *is* this headed? Posted: May 9, 2006 10:15 PM
Reply to this message Reply
> I'm kind of suprised that JavaScript can be used outside
> of web pages. OTOH, DVD menus are very similar to
> content-free web pages, so it's really not that big a
> difference.

JavaScript is just a language. It's no more tied to the web than any other language happens to be, and quite a good language at that (think Lisp dressed up as C). I can't figure out for the life of me why you'd be so surprised.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: my opinion of Javascript Posted: May 10, 2006 9:59 AM
Reply to this message Reply
/* JavaScript is just a language. It's no more tied to the web than any other language happens to be,
*/

PostScript is also a language, but it's not very good for anything outside of page presentation. JavaScript is well-designed (even if it's under-speced), but it was designed with web pages in mind. The ability to use JavaScript outside of web pages shows that it was well-designed.

/* and quite a good language at that (think Lisp dressed up as C).
*/

Yeah, I've read the seven-year-old spec ( http://www.ecma-international.org/publications/standards/Ecma-262.htm ). I've read tutorials on how instance-based inheritance can be used to imitate hierarchy-based inheritance.

/* I can't figure out for the life of me why you'd be so surprised.
*/

Because the JavaScript I actually run into doesn't have support for things like namespaces, modules, or multi-threading. That support isn't prohibited, but it's not standard. Since the compiler is part of the runtime environment, you can't generally expect to have anything available that's not de facto standard. Which leads you to using a small (well-designed), crippled version of JavaScript.

Getting that version of JavaScript to do anything other than web pages is pretty impressive. But, again, HD DVD menus are a lot like content-free web pages.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

When you don't recognize a name ... Posted: May 10, 2006 1:23 PM
Reply to this message Reply
Looks like I should have looked at your profile *before* writing my last post. Now that I've been to http://talideon.com/ , I can see you know more about languages (both programming and natural) than I do. Which explains why you're visiting this site.

Even so, my beef with JavaScript isn't in the language, per se, but in the implementations I'm familiar with.

Keith Gaughan

Posts: 17
Nickname: kgaughan
Registered: Feb, 2003

Re: my opinion of Javascript Posted: May 11, 2006 12:49 AM
Reply to this message Reply
> /* JavaScript is just a language. It's no more tied to the
> web than any other language happens to be,
> */
>
> PostScript is also a language, but it's not very good for
> anything outside of page presentation.

Postscript wasn't designed to specifically to be written by people, JavaScript was.

Take a read of Douglas Crockford's take: http://www.crockford.com/javascript/javascript.html

Also, Brendan Eich's weblog (he's the language's designer) is a good read: http://weblogs.mozillazine.org/roadmap/

> JavaScript is
> well-designed (even if it's under-speced), but it was
> designed with web pages in mind.

No, it was designed with scripting in mind, and had an object model slapped onto it for page manipulation. That's why NS not only used it in their browser for client-side scripting, but used in their servers for server-side scripting.

> The ability to use
> JavaScript outside of web pages shows that it was
> well-designed.

Not necessarily. A well-designed DSL is specific to its domain. A well-designed general purpose language is usable everwhere, but may have certain characteristics (such as the type system, whether it allows side-effects, its concurrency model, &c) that make it better suited in certain areas than others, and in those areas, better suited than other languages.

> /* and quite a good language at that (think Lisp dressed
> up as C).
> */
>
> Yeah, I've read the seven-year-old spec (
> http://www.ecma-international.org/publications/standards/Ec
> ma-262.htm ). I've read tutorials on how instance-based
> inheritance can be used to imitate hierarchy-based
> inheritance.

What you're dealing with in JavaScript is Prototype-based OO: http://c2.com/cgi/wiki?PrototypeBasedProgramming

> /* I can't figure out for the life of me why you'd be so
> surprised.
> */
>
> Because the JavaScript I actually run into doesn't have
> support for things like namespaces, modules, or
> multi-threading.

Nor does C. :-)

As it happens, the first two can be supported programmatically. What isn't supported is a standard method of including files such as an import directive. Support for multi-threading isn't as important as you might think, but a good concurrency model is JS has one, but it's extremely primitive, but fine for the domains in which the language was first used.

> Since the compiler is part of the runtime environment,

JS is usually interpreted.

> Getting that version of JavaScript to do anything other
> than web pages is pretty impressive. But, again, HD DVD
> menus are a lot like content-free web pages.

Less than you might thing: http://script.aculo.us/ Mind you, script.aculo.us is mostly eye-candy, and I've seen JS used for things far more impressive from a technical POV.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: my opinion of Javascript Posted: May 11, 2006 9:56 AM
Reply to this message Reply
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 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).

/* What you're dealing with in JavaScript is Prototype-based OO: http://c2.com/cgi/wiki?PrototypeBasedProgramming
*/

Thanks, I couln't remember the proper term. Of course I could ahve Googled it ...

/* 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.

/* [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].

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. I send plain text down the pipe, the browser tokenizes and compiles that text, then sends it to the interpreter to execute. Although, yes, the three steps can be blurred together.

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).

Keith Gaughan

Posts: 17
Nickname: kgaughan
Registered: Feb, 2003

Re: my opinion of Javascript Posted: May 11, 2006 10:51 AM
Reply to this message Reply
> 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.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: my opinion of Javascript Posted: May 11, 2006 11:46 AM
Reply to this message Reply
It sounds like we've hammered out our positions, and that we agree on the underlying principles. In fact, I think our general opinions are pretty similar.

/* Support for multi-threading isn't as important as you might think,

[snip my response]

Another thing I'd like to disambiguate. Multithreading is just one form of concurrency. ... JS could go down the route of message-passing concurrency ... (i)t could include asymmetric coroutines, ... or it could add multithreading.
*/

My original comment was based on http://www.artima.com/forums/flat.jsp?forum=276&thread=157060&start=0#204771 "Automated testing involves something like a JUnit test. ... However, they all suffer from one core flaw most developers don't immediately realize: JavaScript has only one thread. This means you can't wait for one event to occur without preventing that one event from occurring."

But you are right that concurrency can be added without threads per se.

/* [me] JavaScript doesn't give me the opportunity to do what Nice or Jython do to Java,

[response] 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.
*/

My main point isn't JavaScript-specific, but rather interpreted-language-specific, and it simply boils down to "since each user will generally be able to choose his own runtime environment, I can't rely on non-standard extensions or even many 'standard features' wihtout also providing the implementation of those extensions or features." It's a lot like trying to write platform-independant makefiles: you have to aim for the lowest common denominator; and any time you have to do that, you end up restricted to a crippled subset of something that could be useful.

Yes, you do have browser sniffing as a workaround, but it's only a workaround.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: Where *is* this headed? Posted: May 12, 2006 7:41 AM
Reply to this message Reply
JavaScript can also be used in Adobe Acrobat PDF-Forms. But it isn't supported in (any?) third-party pdf-viewers that don't have the form-filling capabilities.

http://partners.adobe.com/public/developer/pdf/topic_js.html

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Where *is* this headed? Posted: May 12, 2006 9:50 AM
Reply to this message Reply
Yeah, I forgot about that one.

Flat View: This topic has 10 replies on 1 page
Topic: Another Notch for JavaScript: HD DVD Previous Topic   Next Topic Topic: CEDSimply - Nil Pointer Safe Assignment

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use