Rant on web browsers

[Thomas 'PointedEars' Lahn]

[I am biting only because this is my field of expertise, and I am really 
getting tired reading from people not having a shadow of a trace of a 
minimum clue what these languages that I like can and can't do.]

Chris Angelico wrote:

> Random rant and not very on-topic. Feel free to hit Delete and move on.

Why not post on-topic in the first place, and *ask* before being 
presumptuous?  Get better.
 
> I've just spent a day coding in Javascript,

There is no "Javascript".

> and wishing browsers supported Python instead (or as well).

Some browsers do in a way, because of the ECMAScript implementations they 
employ.  Mozilla.org JavaScript 1.7+ is pretty pythonic as compared to, e.g. 
Microsoft JScript.  Array comprehension, Array methods like filter(), and 
iterators/generators come to mind.  This is not a coincidence; Brendan Eich 
has explicitly referred to Python in his blog.

> All I needed to do was take two dates (as strings), figure out the
> difference in days, add that many days to both dates, and put the results
> back into DOM Input objects (form entry fields).

How that would be done would first depend on what you consider a day to be.
(We have been over this elsewhere.)  You can easily compute the difference 
between the time value of Date instances, which is stored as milliseconds 
since epoch, by subtraction (conversion to number is implicit, you do not 
have to call the getTime() method):

  var d1 = new Date(…, …, …, 12);
  var d2 = new Date(…, …, …, 12);
  var ms = d2 - d1;

[I have been told that the 12 hours into the day can avoid problems with DST 
changes.  You may use any hours value that you see fit, even none (which 
defaults to 0).]

Dividing that by the number of milliseconds per "day" (which is conveniently 
written 864e5) would give you a good idea of the number of "day"s (but watch 
out for floating-point precision).

You can also write a method (of Date instances, if desired!) that can take 
calendar days into account – like saying that there are two days "between" 
`new Date(2011, 5, 22)' and `new Date(2011, 5, 24)' –, since overflow on 
Date instances is easily detected:

  Date.prototype.diff = function(d2) {
    // …
  };

  var d = new Date(…);
  var diffInDays = d.diff(new Date(…));

Finally, adding or subtracting calendar days to a date is very simple, of 
course:

  var d = new Date();
  d.setDate(d.getDate() + 2);

> Pretty simple, right? Javascript has a Date class,

No, it does not.  (Have you, by chance, read Flanagan's latest edition on 
the subject, full of misconceptions?)

For your purposes, "Javascript" has no classes at all; if accepted as an 
umbrella term (which I strongly recommend against¹), then the programming 
*languages* it describes in your context all use *prototype-based* 
inheritance.

> it should be fine. But no. First, the date object can't be
> outputted as a formatted string.

Yes, it can.  There are several methods on the Date prototype object for 
that, and you can always write and add your own.

> The only way to output a date is "Feb 21 2011".

Wrong.

> So I have to get the three components (oh and the month is
> 0-11, not 1-12) and emit those.

Not necessarily.  (Yes, the month value is zero-based.  This is not 
particular to ECMAScript implementations.)

> And Javascript doesn't have a simple format function that would force the
> numbers to come out with leading zeroes,

But it is easily written, simplified:

  function leadingZero(n, width)
  {
    n = String(n);
    var len = n.length;
    if (len >= width) return n;

    var a = [];
    a.length = width - len + 1;
    return a.join("0") + n;
  }

> so I don't bother with that.

Your problem alone.
 
> What if I want to accept any delimiter in the date - slash, hyphen, or
> dot?

The most simple way is to convert it so that the string format is understood 
by the Date constructor.  There is precedence for the formats accepted by 
implementations in Web browsers as they are specified in ECMAScript Ed. 5.

However, the most reliable way, unless you are using dates before 100 CE, is 
to parse the components and pass them as separate arguments to the Date 
constructor.  There is even a way to use an Array instance for that (a 
construct method added to Function.prototype or Date), so you can reuse the 
return value of String.prototype.match().

> Can I just do a simple translate, turn all slashes and dots into
> hyphens?

Yes, you can, but it depends on the input format.

> Nope. Have to go regular expression if you want to change
> more than the first instance of something.

Again, that depends on the input format.

> There's no nice string parse function (like sscanf with "%d-%d-%d"), so I
> hope every browser out there has a fast regex engine.

I think sscanf() can be easily written (and is going to be [once again]; 
still working on an efficient sprintf()).

But why accept the date as a string, which is known to be ambiguous, in the 
first place?  Date input should be facilitated by three form controls, not 
one.  The least you should do if you use only one control is to provide a 
date picker widget (HTML5 defines a way to do this without scripting, but so 
far the feature appears to be experimental at least in non-mobile browsers).

> When all you have is a half-ton sledgehammer, everything looks like a
> really REALLY flat nail...

When all you have is a toothbrush, every dirty room must look like taking a 
lifetime to get cleaned up…  RTFM!
 
> Plus, Javascript debugging is annoyingly difficult if you don't have
> tools handy.

Script debuggers are built into most recent Web browsers.  AFAIK of the Big 
6[tm] (IE, Fx, Op, Cr, Sf, Kq) it is only Firefox which requires e.g. 
Firebug to be installed as an extension.  But installation of that is very 
straightforward, and useful.

> I need third-party tools to do anything other than code blind?

No, you don't.  WebCore-based browsers et al. have debuggers built-in 
(Ctrl+Shift+J etc.)  All widely distributed Web browsers have an error 
console built-in, and almost all graphical Web browsers to date support the 
`javascript:' URI scheme, with which you can test script code from the 
Location/Address Bar even without an error console (just be sure that you 
use the `void' operator or other means that return an undefined-compatible 
result).

> Thanks.

You're welcome.

> Oh, and "int i" is illegal in Javascript.

That depends on your idea of "Javascript".  It is certainly a syntax error 
in implementations of ECMAScript Ed. other than 4.

> Whoops. That one is my fault, though.

Yes, those languages are loosely typed.  Like Python, BTW.

> Javascript's greatest strength is that it exists in everyone's
> browser.

A language named "Javascript" exists in exactly no browser.¹

> That is simultaneously it's worst failing, because it becomes
> nigh impossible to improve it.

No, it has been done.

> If Chrome's V8 starts supporting new features and everyone else's JS
> engines don't, we can't use those features.

Yes, we can.  You only cannot because you are too lazy.

> Even if they're added to the standard, there'll still be old
> browsers that don't support things.

You can deal with incompatible syntax extensions the same as before with, 
e.g. Netscape 4.  eval() comes in handy there, but you lose performance.

You can deal with API extensions the same as before, by run-time feature-
testing (which costs performance as well, but when cleverly done not nearly 
as much).

Obviously you have not the slightest idea what you are talking about.  But 
that is a common trait among JavaScript/ECMAScript neophytes.

> The only way to add to the language is to dump stuff into a .js file and
> include it everywhere.

No, you can make adjustments on an as-needed basis (much like in Python).
 
> But if anyone feels like writing an incompatible browser, please can
> you add Python scripting?

Get yourself informed for a change!

______________
[1] <http://PointedEars.de/es-matrix>
-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.