Tuesday, November 10, 2015

Grade 12 Math: Something Other than Calculus

In the US and Canada, the mathematics taught in the senior year of high school is typically linear algebra (matrices, determinants, inversion, etc.) and calculus, meaning single-variable differentiation and integration.


I'm not sure this is wise, for two reasons. First, linear algebra and calculus are remarkably useless for people who aren't headed for STEM occupations. They are vital for some engineers and scientists, who use them all the time, but don't get much use outside these disciplines. I work in a pretty technical domain -- I'm a software developer -- but I've used calculus exactly once outside of schoolwork and linear algebra never at all.

Second, universities usually insist of teaching these two topics anyway. In STEM programs, they are typically covered in mandatory courses in the first year. Students whose high schools did a good job get to coast for half a year, while the less fortunate catch up, which is just wasted time.

If we eliminated linear algebra and calculus from high school curricula, leaving them to those who are headed for professions where they are actually useful, we could replace these courses with some other forms of mathematics. There are plenty of choices: abstract algebra, topology, geometry, combinatorics, and the list goes on.

Of these, formal logic and statistics are particularly promising. Formal logic attempts to rigorously determine the truth value of claims, while statistics handles approximations and drawing inferences from observed behavior. As such, they are particularly useful for sorting through the mass of questionable claims we all face in an information society, to find the truth among the wishful thinking, half-truths, and outright lies. This makes them valuable aids to good citizenship, which is something we should be aiming everyone towards. And as actual domains of mathematics, they can be made as rigorous and challenging as the less useful courses they would be replacing.

Tuesday, March 17, 2015

Four Solutions to the JavaScript Problem

If you have worked with JavaScript, you are surely familiar with a long litany of complaints about the language. Some developers are frustrated by its very loose, dynamic nature, while others point to odd behaviors such as hoisting and conversion-on-equality as big problems. (More here.)

I don't want to belabor the problem itself; plenty has been written about that already. Instead, let's consider the solutions. There are essentially four types, at increasing distances from plain JavaScript.


Use JavaScript Carefully: Program in JavaScript directly, but avoid or work around the sharp edges of the language, such as weak typing and the lack of a module system. In effect, you program in a restricted sub-language of JavaScript. This is what Douglas Crockford and Stoyan Stefanov advocate in their books. Crockford goes even further with JSLint, a verifier that strictly enforces the use of his dialect of JavaScript. 

Add Annotations: Add hints about the programmer's intent to the code, typically with type annotations. This requires a compiler to process the language, but both the input and output languages of the compiler are JavaScript -- perhaps even identical to the input if the annotations read as comments in JavaScript itself. This is much of what TypeScript and Closure try to do, although their compilers go a bit farther, adding things like a module system.

Use a Neighboring Language: Program in a fundamentally different language than JavaScript. But keep the data model and functionality close enough that translating to JavaScript isn't too hard. With a small semantic distance, the output is recognizably similar to the original code, making it useful for debugging. CoffeeScript and PureScript follow this model. 

Use Something Else Entirely: It is possible to compile virtually any programming language to JavaScript, although more distant languages require a lot of extra JavaScript code output to bridge the semantic gap. And of course more code means more execution time. Kiss source-level debugging goodbye too. GWT and Haste do it this way.

Where you want to be on this continuum depends on how troublesome you find JavaScript and how much control you are willing to hand over to a compiler and runtime system.