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.
"The pen is mightier than the sword if the sword is very short, and the pen is very sharp." -- Terry Pratchett
Tuesday, November 10, 2015
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.
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.
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.
Subscribe to:
Posts (Atom)