"Over the past year and a half I've been spending more and more of my time working with Mozilla's latest project, Firefox OS. During that time I've fallen in love with the project and what it stands for, in ways that I've never experienced with a technology platform before." I'm not convinced just yet. I hope it succeeds, but I just doubt it actually will.

I think you two are getting overly hyped up over what is, at the end of the day, a matter of preference about which technologies you like better.

galvanash,
Yes, javascript promises to lower the barrier to entry for app development. But you've said alot of things I disagree with. Like static typing...it does have a use (though whether you benefit from it is a different matter), it explicitly limits the number of states a variable may hold and helps catch errors at compile time.

In some languages, string concatenation and arithmetic addition are separate operators to help resolve the ambiguity, but javascript depends on inferred typing.
var a = x.foo() + 'x'; // what is a?

For this reason, I'd argue javascript is a poor choice for mission critical applications like those at NASA. There are more problems, like the inability to define proper "classes", which make javascript both slower and less error proof. Again, maybe you prefer not to use classes and find the prototype substitute good enough for you. But whether it's an enhancement or restriction of the language depends on your point of view - it's a matter of opinion.

Also, we've build other languages on top of javascript because browsers don't give us much choice, not because it particularly makes sense to do so otherwise.

Nelson,

You are right that no single language is good for everything. But you must accept that portability is very important and useful to many developers and users, they should be able to write once, run anywhere without needing to rewrite it again... You can dismiss portability for yourself, but it really doesn't make sense to dismiss the utility for others.

Like static typing...it does have a use (though whether you benefit from it is a different matter), it explicitly limits the number of states a variable may hold and helps catch errors at compile time.

Exactly. I don't like languages that limit the number of states a variable may hold. And the types of errors that are actually caught by type checking at compile time are generally trivial typos and such.

That said, if you do proper unit testing (something you should be doing in either type of language) all the pros of static typing disappear - except for it being faster to compile. Hence why I said that is its only real strength.

var a = x.foo() + 'x'; // what is a?

a is a variable

For this reason, I'd argue javascript is a poor choice for mission critical applications like those at NASA.

Most of the space stuff tends to use plain old C, which might be statically typed but it isn't strongly typed - which is arguably just as bad from an "avoiding errors" point of view...

Then again, I have read they use quite a bit of Python at JPL - Python isn't all that different from javascript fundamentally - both are dynamically typed. It sure is prettier though...

There are more problems, like the inability to define proper "classes", which make javascript both slower and less error proof.

How does using prototypes instead of class make things slower and less error proof? Its just a different way to skin the cat - they both get the job done equally well if you understand the paradigm.

Again, maybe you prefer not to use classes and find the prototype substitute good enough for you.

I don't consider prototyping a "substitute" for classes - it is the sane way to do it

But whether it's an enhancement or restriction of the language depends on your point of view - it's a matter of opinion.

Agreed.

Also, we've build other languages on top of javascript because browsers don't give us much choice, not because it particularly makes sense to do so otherwise.

Whether its javascript or some other language - it makes no sense to deliver an opaque intermediary language representation to a browser that is designed to render human readable markup. The human readable part is important for a multitude of reasons, and that includes the logic too...

"Exactly. I don't like languages that limit the number of states a variable may hold."

Other than an ADT, can you give me an example where storing multiple types in one variable is good practice?

VB supported both typed and untyped code, plus it did not overload '+' as a concatenation operator, both of these traits help resolve ambiguities we have in javascript.

"That said, if you do proper unit testing (something you should be doing in either type of language) all the pros of static typing disappear - except for it being faster to compile."

This is not it at all. Throw out compilation speed all together and you'll still find that some programmers prefer rigid constraints to inferences. If I know that I want a boolean, there's no reason the language should force me to use a variable than can store a float, an integer, a string, an object, an array, etc. For me, this is a shortcoming of JS REGARDLESS of performance. Even if variants are better in your opinion, they're not better for everyone.

"How does using prototypes instead of class make things slower and less error proof? Its just a different way to skin the cat"

The problem with JS objects is the same as the problem with it's variables: it doesn't permit the programmer to be explicit about his intentions at compile time.

As for performance, javascript's objects are actually hash tables, very powerful but they're not anywhere as efficient (space or computation) as a static language memory structure. While it is true that JS objects are more flexible at run time, that benefit is completely lost on programmers who (in their own opinion) would benefit more from compile time structure/type checking.

"Whether its javascript or some other language - it makes no sense to deliver an opaque intermediary language representation to a browser that is designed to render human readable markup."

I don't think being HTML or JS are intrinsically human readable unless that code was written by a human. Ever tried to use a JS optimizer to remove variable names/spacing/comments? It's impossible to read again without reverse engineering it. So to the extent that a human wrote the code, then having source code is nice (even if irrelevant to most users). But I doubt many devs will have reason to work with the intermediate representation even if it is in Javascript.

So for running many languages in the browser, we'd probably be better off with a well defined bytecode that can easily be decompiled back into source form (tools exist to do this for java).

"It makes perfect sense. I'm not in the business of caring about what lazy developers prefer. Anyone using HTML/JS to write run anywhere app is pretty much the worst kind of developer I know."

Wow Nelson, I think you might have initially started out defending a sound principal, but your argument is becoming absurd. Writing portable code is ultimately about not having to reimplement the same thing everywhere. You can call it lazy if you want, but I'll call it being efficient.

The WWW, for all it's problems, could not be as ubiquitous and transparent as it is today if everyone used their own protocols and different standards. Unless you believe in segregating the online population, it's a good thing that everyone can visit each other's websites with the expectation that they will work everywhere else.

It makes perfect sense. I'm not in the business of caring about what lazy developers prefer. Anyone using HTML/JS to write run anywhere app is pretty much the worst kind of developer I know.

Wake up, developers. At one point, people were more principled than this.

I'm very principled... One of my first principles is that I don't believe that development is the process of becoming attached at the hip to a particular vendor's idea of the right way to do things. HTML/JS might not be perfect, but it has one very significant feature that no other development platform has - no one company is steering the boat.

And since you want to resort to name calling... What is being content to slop up Microsoft or Apple's latest dog food for the sake of it making things easier for you? That sounds pretty lazy to me.

My development platform is the world - yours is just the latest gadget fad...