I couldn’t help but ask myself “why don’t these people just learn JavaScript?” The answer is easy. I’ve been slowly learning JavaScript for years and I’m still not there—because I don’t have much time to spend. And the other question is “why don’t we hire a JavaScript person to write the JavaScript part?” There are many possible answers to this. One is that we like to be able to do everything ourselves, something valuable in small and hobby projects. Another possibility is that good JavaScript programmers are hard to find. And going from a team of one to a team of two people is no small step.

I can tell you about myself. For about 10 years, I ignored and resisted all that.

Yes, like everyone, I’m always busy, and there are tons of things to learn anyway. I had wanted to learn a little JavaScript since 2000 but I had never got to it.

But I think it may have been more to it than that. JavaScript was a bad language. I didn’t want to program in a bad language. I was using serious stuff like Python and Django. I was too self-important to engage in inferior tools.

It’s not just conceit. Very often there’s a new fashion that explodes, only to die off a bit later. Like XML, for example. In the last 30 years I avoided investing in technologies that didn’t seem right to me, and usually I was proven right. JavaScript was the exception.

I think that many Python people acted the same as I.

A month ago I participated in the Django Conference Europe, and I was surprised at how people are approaching the JavaScript problem. This conference was the incentive for me to write this series. What I saw at the conference is the subject for next time.

• 2008: Google releases Chrome, which includes the incredibly fast V8 JavaScript engine

• 2009: Ryan Dahl creates Node.js, a command-line JavaScript engine based on V8

• 2013: Facebook creates React, a JavaScript framework for building UIs

• 2014: Sebastian McKenzie creates Babel, a compiler that transforms from one version of JavaScript to another

• 2015: ECMA publishes the final version of ES6 aka ES2015, a much better version of JavaScript

This concise list is not very informative, so if you are interested but haven’t read my previous posts it’s better to do so, starting from “How JavaScript became popular—part 1”.

What did the Python people and other non-JavaScript people do during this revolution? This is a story for next time.

<h1>How JavaScript became popular—part 5</h1>

<p class="subtitle">The frameworks changed the way web applications work</p>

...

If the user clicks on a link, the browser makes a new request and receives another response in HTML, i.e. another web page, which replaces the page that was previously visible.

Modern web applications written with the so-called “JavaScript frameworks” work differently. A JavaScript program that runs on the browser makes a request and receives a structured response like this:

{
    title: "How JavaScript became popular—part 5",
    subtitle: "The frameworks changed the way web applications work",
    ...
}

The JavaScript program reads the data from the response and creates the HTML itself, which it then shows on the browser.

The result is web applications that are much faster and more pleasant to use for the user. You can feel the difference when you use different kinds of web applications.

There are three JavaScript UI frameworks, i.e. libraries, that help programmers write such modern applications: React (2013), Vue.js (2014), and Angular (2016). These were the last thing that contributed to JavaScript’s exploding popularity.

Related:

• How JavaScript became popular—part 4

Many programmers would rather not have anything to do with such an abomination, but JavaScript was the language of the browsers, and they couldn’t avoid it. One solution was to create new programming languages which compiled to JavaScript, such as CoffeeScript (2009) and Microsoft’s TypeScript (2012), which today is very widely used. In 2014 a teenager created Babel, a library that could compile the next version of JavaScript to the previous one (today it can also compile TypeScript and many other JavaScript extensions). This was important because the 2015 version of JavaScript had several new features that made it somewhat bearable, but it would be years before all browsers supported these features.

We are nearing the end of this story, and to complete it we need to talk about the JavaScript UI frameworks, a story for next time.

Related:

• How JavaScript became popular—part 3

• You only needed one language, JavaScript, which could run both on the server and on the browser.

• Some code could be shared between browser and server. Otherwise we often write the same piece of functionality in e.g. Python, so that the server can run it, and in JavaScript, so that the browser can run it.

• Node.js was very fast.

• JavaScript is an asynchronous language by design. I’m not going into detail about what this means, but it’s a good thing for servers. Python only got standard asynchronous features in 2014, whereas JavaScript was asynchronous in the core from day one in 1995.

It’s therefore no surprise that a year and a half after the first release of Node.js, Express.js, a web application framework for the server, was released.

There was a problem though. JavaScript sucked. It had some good parts, but it was a bad language. But this is a story for next time.

anthony@seska:~$ node
Welcome to Node.js v14.17.0.
Type ".help" for more information.
> console.log("hello world")
hello world
undefined
> 

This is very similar to doing the same thing in Python:

anthony@seska:~$ python3
Python 3.8.7 (default, Dec 23 2020, 12:32:20) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print("hello world")
hello world
>>> 

Now JavaScript was a language you could run everywhere—not just in the browser.

It’s amazing how things took off from there. But this is a story for the next time.

The JavaScript engine is the part of the browser that executes JavaScript. I like the term “engine” because it avoids questions concerning the difference between interpreters and compilers. Every browser has a JavaScript engine: Firefox’s is called SpiderMonkey and Safari’s is Nitro. Chrome, Edge and Opera all use the same JavaScript engine, V8, originally released as part of Google Chrome in 2008.

What was notable about Google Chrome and V8 was that it was fast. It analyzed the program and compiled the parts that could be compiled, running them in native speed. It also used many other optimizations. Chrome’s competitors soon copied these features, and today all JavaScript engines are equally fast. A few months ago I made some tests and I was surprised to see that, in many cases, JavaScript is five times faster than Python (although still much slower than pure compiled languages such as C).

The next milestone was the creation of “Node.js” in 2009. But this is a story for next time.

• Programming is intrinsically pleasurable.

• Most software is substandard.

• Most software is substandard because programming is intrinsically pleasurable.

Technically we program in order to solve the user’s problem. However, we get absorbed by the pleasure programming gives us, and therefore we focus on our pleasure rather on someone else’s (the user’s) pain. At least that’s what Daniele says. The problem is worsened by the fact that bad software usually doesn’t result in serious damage—it usually causes irritation or inconvenience. Therefore, programmers have the luxury to not care much about the actual problem they’re supposed to be solving.

Many of these observations apply to science also. Scientists do science because it gives them pleasure. The outcome of bad science is rarely life threatening. Is this the reason science is often substandard? I have some doubts on that but it’s certainly thought-provoking.

metonic_year = year mod 19
century = [year / 100]
quadricentennial = [century / 4]
p = [(13 + 8 × century) / 25]
M = (15 - p + century - quadricentennial) mod 30
ndays_equinox_to_full_moon = ((30 - 11) × metonic_year + M) mod 30

How can we improve the names for p and M? Things are becoming difficult here. M is a correction that applies to the century, and p is so hard that Gauss got it wrong. He initially thought it was [century / 3], which gave wrong Easter dates from the year 4200 onwards. Gauss found about the error soon and made several failed attempts at fixing it, until a student of his finally found the correct expression about 15 years after the original paper.

The second observation is the number 11 in the last expression. The original algorithm doesn’t say 30 - 11, it says 19. Good luck explaining to someone that this is not the length of the Metonic cycle. Initially I had DIFF_BETWEEN_12_MOONS_AND_A_YEAR in place of 11, but this made the expression too long. Besides, I’d need to also use constant names for 30 (presumably the length of the lunar cycle), 19 (the length of the Metonic cycle) and more. It would make it harder to read.

One problem I’d try to correct is that the result isn’t actually the days from equinox to full moon—it’s actually the days from the day after the equinox to the day after the full moon. I might try to keep the name ndays_equinox_to_full_moon and instead change the algorithm so that the name is accurate. In fact, trying to improve the name of a variable often leads to entirely refactoring the code.

If I wanted to write a paper on this I’d continue these improvements, but I think I’ve said enough and I’ll stop here.

Why ten days? Why not nine or eleven?

If you ask a search engine this question, you’ll find lots of texts repeating the information that they wanted to restore the calendar as it was in 325 A.D., the date of the First Council of Nicaea.

But the number of additional leap days in the Julian Calendar from 325 to 1582 is one for each of the years 500, 600, 700; 900, 1000, 1100; 1300, 1400 and 1500. A total of nine days. Or, another way to calculate it, (1582 - 325) / 100 * 0.75 = 9.4 days.

Why ten days?

To get the answer, we need to unearth the Pope’s 1582 decision. There, it says that they have arranged “to restore the vernal equinox to its original place from which it has already receded by about ten days since the Council of Nicaea”. A little bit further below it becomes more specific, decreeing that the vernal equinox is to be restored to the place where it “was placed by the fathers of the Council of Nicaea at the twelfth day before the Kalends of April” (this is 21 March).

Conclusion: always look up the original reference.

Here’s a similar question: Was the 1582 decision right in that the Council of Nicaea had placed the equinox on 21 March? Again, we’d need to consult the original reference, but it seems that the relevant part of the Council proceedings has been lost.

a = year mod 19
b = year mod 4
c = year mod 7
k = [year / 100]
p = [(13 + 8k) / 25]
q = [k / 4]
M = (15 - p + k - q) mod 30
N = (4 + k - q) mod 7
d = (19a + M) mod 30
e = (2b + 4c + 6d + N) mod 7

• Easter is on 22 + d + e March or d + e - 9 April

• Exception 1: if d = 29 and e = 6, Easter is on 19 April rather than 26 April

• Exception 2: if d = 28 and e = 6 and (11M + 11) mod 30 < 19, Easter is on 18 April rather than 25 April

What is better? The conciseness of this math? Or the long variable names and splitting into functions, that makes it much more self-explanatory? I guess that the answer is “it depends”. Still, I think that math has too much emphasis on conciseness. I often read a paper and I wonder “what did we say M is?” and go some pages back to remember. Maybe math should take some ideas from programming and relax the rule of using single-letter variables. But of course it’s hard to break with centuries of tradition.

It turns out that running it isn’t that important. What is important is for readers to be able to read it. While Python is easy for uninitiated to read, JavaScript is much less so, not because it’s a worse language, but because it has variable declarations; some people will say that this is a good thing, but it definitely creates some noise.

This shows that there’s no such thing as a language that is universally better than other languages. Which one to choose depends. I’ve written about this in the past.

In any case, after fixing the variable names, and before going on to improve its readability further by splitting it in smaller functions, I rewrote it in Python. You can see it (split in smaller functions) here. Here’s an extract:

def calculate(self):
    self.find_days_from_equinox_to_full_moon()
    self.find_days_from_full_moon_to_sunday()
    self.find_easter_sunday()

While the program is getting much better, it still has many improvements that need to be made. But the thing is, it’s quite long. More on this next time.

• Did you understand the program clearly? No.

• Did you have a clue what’s going on? No.

In the end of this post I’m showing you that very same program with only two changes:

1. I’ve renamed most of the variables.

2. I’ve moved some variable definitions so that they’re nearer to where they’re being used.

Let’s consider the same two questions:

• Do you understand the program clearly? Still no.

• Do you have a clue what’s going on? Yes!

Just by renaming a few variables you now have a clue what’s going on without needing to study Gauss’s paper.

Of course it’s less concise than what it was, but it’s our time and brain power that are in scarcity rather than ink and paper, much less storage bytes.

However, it still needs much improvement. Anyway, here is its current form:

const DAYS_IN_12_MOONS = 12 * 29.5;
const DIFF_BETWEEN_12_MOONS_AND_ONE_YEAR = 365 - DAYS_IN_12_MOONS;

function getEasterDate(year) {
  let month;
  let dayOfMonth;

  const yearNumberInMetonicCycle = year % 19;
  const century = Math.floor(year / 100);
  const p = Math.floor((13 + 8 * century) / 25);
  const quadricentennial = Math.floor(century / 4);
  const M = (15 - p + century - quadricentennial) % 30;
  const daysFromEquinoxToFullMoon = (
    (
      (30 - DIFF_BETWEEN_12_MOONS_AND_ONE_YEAR)
      * yearNumberInMetonicCycle + M
    ) % 30
  );

  const b = year % 4;
  const c = year % 7;
  const N = (4 + century - quadricentennial) % 7;
  const daysFromFullMoonToSunday = (
    2 * b + 4 * c + 6 * daysFromEquinoxToFullMoon + N
  ) % 7;

  const exception1 = (
    daysFromEquinoxToFullMoon === 29
    && daysFromFullMoonToSunday === 6
  );
  const exception2 = (
    daysFromEquinoxToFullMoon === 28
    && daysFromFullMoonToSunday === 6
    && (11 * M + 11) % 30 < 19
  );
  if (exception1) {
    month = 4;
    dayOfMonth = 19;
  } else if (exception2) {
    month = 4;
    dayOfMonth = 18;
  } else {
    month = 3;
    dayOfMonth = (
      22 + daysFromEquinoxToFullMoon + daysFromFullMoonToSunday
    );
    if (dayOfMonth > 31) {
      month = 4;
      dayOfMonth -= 31;
    }
  }
  return [month, dayOfMonth];
}

There are only seven tests. Are they enough?

Maybe. To be exhaustive we’d need to write 5.7 million tests (Easter dates repeat after that, or so they say), and most models have infinite cases. Normally what we do is try to catch the edge cases and get going. At some point we may discover a bug in another edge case, so we add another test. And so the story goes.

How do you find the expected result? How do you know that on 1598 the Easter was on 22 March?

In this particular case I used another Easter program (ncal) that I believe to be correct. The person who writes the first such program needs to test it by manually implementing the Church’s method to determine the expected results.

If your model is novel and you have nothing to compare it to, the best way to test the code is to have your associate solve the test case by hand, or in Excel, or in some other way, and sit down together to work out any differences between his results and your results. While this is time consuming, it’s exciting work, and you will have a rewarding feeling of trusting your code (and your model) when you’re done.

Finally, if you have code without automated tests, but you have used it for years and trust it, you can use it to solve the test cases and assume they’re correct. This is useful if you want to refactor the code but are afraid you might break something.

The testing code looks very verbose. Wouldn’t it have been better to create a table of expected results and loop over it to check?

In general no. Tests must be dead simple, without loops or ifs.

In this particular case, I think creating a table and a loop would have made sense. But in the thousands of tests I’ve written, I don’t recall ever having done anything like this. If I had shown you a table, it would have been hard to convince you that this is only a rare exception. I thus wrote the tests in the normal way.

test('earliest possible date', () => {
  expect(getEasterDate(1598)).toEqual([3, 22]);
});

test('latest possible date', () => {
  expect(getEasterDate(1666)).toEqual([4, 25]);
});

test('19 April special case where d = 29 and e = 6', () => {
  expect(getEasterDate(1609)).toEqual([4, 19]);
});

test('non-special 19 April', () => {
  expect(getEasterDate(1615)).toEqual([4, 19]);
});

test('18 April special case where d = 28 and e = 6 and more', () => {
  expect(getEasterDate(1954)).toEqual([4, 18]);
});

test('non-special 18 April', () => {
  expect(getEasterDate(1965)).toEqual([4, 18]);
});

test('correct p', () => {
  expect(getEasterDate(4200)).toEqual([4, 20]);
});

The problem is I will be changing the code. How will I know I haven’t broken something? By going to the web interface and trying it out? This would be tedious and wouldn’t work well. Instead, I wrote a few automated tests. All I do now is enter a command on my terminal. It runs the tests, and after two seconds it tells me they passed.

Here are the tests, which you can probably understand easily even if you don’t know this language:

test('earliest possible date', () => {
  expect(getEasterDate(1598)).toEqual([3, 22]);
});

test('latest possible date', () => {
  expect(getEasterDate(1666)).toEqual([4, 25]);
});

test('19 April special case where d = 29 and e = 6', () => {
  expect(getEasterDate(1609)).toEqual([4, 19]);
});

test('non-special 19 April', () => {
  expect(getEasterDate(1615)).toEqual([4, 19]);
});

test('18 April special case where d = 28 and e = 6 and more', () => {
  expect(getEasterDate(1954)).toEqual([4, 18]);
});

test('non-special 18 April', () => {
  expect(getEasterDate(1965)).toEqual([4, 18]);
});

test('correct p', () => {
  expect(getEasterDate(4200)).toEqual([4, 20]);
});

In fact, I started to add more features to it before it was even ready. I should have written a purely Gregorian version, but I incorporated Julian before I even started. Now that I understand my mistake I’ll undo it. I’ll just throw away all Julian/Orthodox code, which is about 25% of all code.

The revised function (shown below) is also confusing, but at least it looks almost identical to Gauss’s algorithm (that is, the algorithm is also confusing). My seemingly impossible task is to make the program understandable without comments and without needing to explain it. But before that we need to write some tests, coming in my next post.

function getEasterDate(year) {
  let month;
  let dayOfMonth;

  const a = year % 19;
  const b = year % 4;
  const c = year % 7;
  const k = Math.floor(year / 100);
  const p = Math.floor((13 + 8 * k) / 25);
  const q = Math.floor(k / 4);
  const M = (15 - p + k - q) % 30;
  const N = (4 + k - q) % 7;
  const d = (19 * a + M) % 30;
  const e = (2 * b + 4 * c + 6 * d + N) % 7;
  if (d === 29 && e === 6) {
    month = 4;
    dayOfMonth = 19;
  } else if (d === 28 && e === 6 && (11 * M + 11) % 30 < 19) {
    month = 4;
    dayOfMonth = 18;
  } else {
    month = 3;
    dayOfMonth = 22 + d + e;
    if (dayOfMonth > 31) {
      month = 4;
      dayOfMonth -= 31;
    }
  }
  return [month, dayOfMonth];
}

The heart of the program is the `getEasterDate()` function, which I include below. I wrote it quickly and it suffers from the problems most scientific code suffers. Essentially it’s hard to understand. But the problem is that the algorithm itself is hard to understand. Can we make the algorithm and the program easier to understand? I will start exploring this question in my next post.

Here is the boring code I promised (the full thing is at https://github.com/aptiko/easter):

function getEasterDate(year, type) {
  let month;
  let dayOfMonth;
  let M;
  let N;

  const a = year % 19;
  const b = year % 4;
  const c = year % 7;
  if (['julian', 'orthodox'].includes(type)) {
    M = 15;
    N = 6;
  } else {
    const k = Math.floor(year / 100);
    const p = Math.floor((13 + 8 * k) / 25);
    const q = Math.floor(k / 4);
    M = (15 - p + k - q) % 30;
    N = (4 + k - q) % 7;
  }
  const d = (19 * a + M) % 30;
  const e = (2 * b + 4 * c + 6 * d + N) % 7;
  if (d === 29 && e === 6) {
    month = 4;
    dayOfMonth = 19;
  } else if (d === 28 && e === 6 && (11 * M + 11) % 30 < 19) {
    month = 4;
    dayOfMonth = 18;
  } else {
    month = 3;
    dayOfMonth = 22 + d + e;
  }
  if (dayOfMonth > 31) {
    month = 4;
    dayOfMonth -= 31;
  }
  if (type === 'orthodox') {
    dayOfMonth += julianDifference(year);
  }
  if (dayOfMonth > monthDays(month)) {
    dayOfMonth -= monthDays(month);
    month += 1;
  }
  return [month, dayOfMonth];
}

Gauss seems to be the first to have created an algorithm in 1800, which he republished with fixes in 1816. This is Gauss’s 1816 algorithm:

a = year mod 19
b = year mod 4
c = year mod 7
k = [year / 100]
p = [(13 + 8k) / 25]
q = [k / 4]
M = (15 - p + k - q) mod 30
N = (4 + k - q) mod 7
d = (19a + M) mod 30
e = (2b + 4c + 6d + N) mod 7

• Easter is on 22 + d + e March or d + e - 9 April

• Exception 1: if d = 29 and e = 6, Easter is on 19 April rather than 26 April

• Exception 2: if d = 28 and e = 6 and (11M + 11) mod 30 < 19, Easter is on 18 April rather than 25 April

Easter is, supposedly, on the Sunday after the first full Moon of the spring, where the spring supposedly starts on the equinox. But people in the Eastern Orthodox countries can see that, more often than not, this is not the case. Acute observers will notice that, sometimes, the Catholic/Protestant Easter is also off, such as in 2019, when the equinox was on 20 March 21:58 UTC, the full Moon was a few hours later, on 21 March 01:43 UTC, and yet Easter was on 21 April.

What happens is that the Church didn’t want to need to ask an astronomer each time. Especially until a few centuries ago, an annual announcement by the head of the Church would be hard to communicate to remote places. So they devised a method with which Easter can be calculated easily by anyone. Here are the details for the Julian Easter (which is the one celebrated by the Eastern Orthodox Church):

• It is assumed that the day of equinox is always 21 March (which in the Julian calendar is now off by 13 days, i.e. it is 3 April).

• It is assumed that, every 19 years, the Moon phases recur at the same day of the year (the “Metonic cycle”).

• A table (with 19 entries) provides the full Moon date for each of these 19 years.

The Gregorian Easter is calculated in a similar manner, but it is more accurate, e.g. it has a provision for the fact that the Metonic cycle is off by roughly one day per century. Interestingly, the Julian calendar as a whole is off by roughly one day per century, and that error partially cancels out the Metonic cycle’s error. As a result, the Julian Easter’s “full Moon” is off by less than a week, which is why sometimes the Gregorian and the Julian Easter coincide.