How much does it cost to provide a college education?

The price of college-level study varies widely. At the top end, Harvard charges some $47,000 in tuition and fees per year. At the low end, CCNY charges in-state residents $3165 per semester. Subsidies and prestige pricing abound in higher education, obscuring actual costs dramatically. But how much does it actually cost to provide a college education? Let's try for a ballpark figure.

A college education usually consists of four years of study, two semesters per year, with maybe five courses per semester. That's a total of 40 courses.

The main expense of running a college is the professors who teach the courses. Suppose each professor teaches four course sections a year, two per semester. That will leave him or her time for a bit of scholarship during the school year, as befits a scholar who is not purely an instructor. The loaded cost of a professor might be $150,000 per year, including benefits. And each course section has 100 students on average. That comes out to $150,000/(4*100) = $375 per course for each student.

40 courses per student at $375 each comes to $15,000. But that's just the cost for the instructor. Colleges also have libraries, lecture halls, labs, office space, recruiting expenses, and a hierarchy of supervisors and deans, all of which come under the heading of "overhead". How high might those costs be?

Colleges typically take 50% off the top of every research grant awarded to their faculty members for overhead expenses, which suggests a useful and simple ratio of 1:1 in primary costs to overhead. So the original $15,000 becomes $30,000. Of course, that $30,000 excludes quite a bit: room and board, text-books, and general living expenses for those who aren't still living at home. But that's our estimate: a bare-bones college education costs $30,000.

Why the 2008 market crash had no satisfying conclusion

After the 2008 financial crash, the electorate was left in a distinctly unpalatable position. The government had been forced to step in to rescue several major institutions, leaving the taxpayers with a hefty bill, but nearly all of the key players in the market were left standing. Things had gone wrong but no one, it seemed, could be blamed and punished.

In my view, the resolution was so unsatisfying because the blame for the crisis stretched far. There was no single institution or even sector that single-handedly caused the problem; many, many people and institutions played a part.

• Ordinary homeowners sought mortgages they couldn't really afford.
• Mortgage brokers sold mortgages to people with very poor finances, who probably should not have been in the mortgage market at all.
• Originate-and-sell lenders didn't particularly scrutinize the mortgages they were issuing, because they could always sell them on.
• Investment banks sliced and diced pools of increasingly crappy mortgages into ever more baroque bonds, without a proper analysis of systemic risk.
• Bond rating agencies went along with what the banks were building, happy to rate them AAA as long as they collected their fees. 
• Institutional investors bought the baroque bonds based on ratings alone, without scrutinizing the internals.
• The US Fed kept interest rates low for a long, long time, exacerbating the housing bubble that drove the system.

Who was to blame? All of them? None of them? Probably all of them, to some extent. But with no clear villain, there was no one to punish, and no sector which could be targeted for clear reforms. Hence the dissatisfaction.

Should you use Haskell for a new project?

What are the pros and cons of trying to do a new project in Haskell, as opposed to some more mundane imperative language like Python or Java? Let's assume for the sake of argument that you are doing this for an employer, rather than for yourself as a side project. And let's also assume that you have a bit of Haskell experience, but like most programmers most of your work has been in mundane imperative languages.

To begin with, there are a couple of concerns that might kill an attempt to use Haskell.

1. You might not be able to get management approval. Haskell is an obscure language with a reputation for difficulty. The bosses might well say no. 
2. You might need to work with an existing codebase in something like Java or Python. Not possible from Haskell.

If those don't kill the project, there's the cost-benefit tradeoff. On the benefits side:

1. Haskell code is very concise. (definitely) And greater concision means faster development. (possibly) 
2. Haskell code is less likely to contain errors, because of very strict typing. (probably) 
3. Haskell coders are disproportionately capable, because the language is obscure and difficult. (probably)

On the costs side:

1. You have much more experience in other languages. It would take at least a year, maybe two before you'd be up to pro standards in Haskell. 
2. The community of Haskell programmers is small. It might be difficult to hire anyone if the project grew; you might be faced with training someone from scratch, not just in a new language, but in a new programming paradigm.

So, this isn't anything like a slam dunk. Quite the opposite, actually. There are a couple of issues that might nix the project right up front, and then a daunting cost-benefit calculation.

Reviewed: Masterpieces: The Best Science Fiction of the Twentieth Century

Masterpieces: The Best Science Fiction of the Twentieth Century is an anthology of science fiction short stories compiled by Orson Scott Card, one of the giants of the genre. He's the man who wrote Ender's Game and its many many sequels.

The anthology collects 27 short stories spanning much of the twentieth century, from 1936 to 1995. The best of the stories are very good indeed. "The Road Not Taken" is an intriguing what-if by Harry Turtledove. "'Repent, Harlequin!' Said the Ticktockman" has an appealing rebelliousness and Harlan Ellison's awesome prose. "Dogfight" by Gibson and Swanwick is gritty and fierce. And "The Ones Who Walk Away from Omelas" by Le Guin poses a really hard moral question.

But, but, but. There are too many stories that are just sort of ok-ish -- 16 out of 27 by my count. If you're stepping up to the plate with "Masterpiece" stenciled on your bat, you should be whiffing less often than that.

The most puzzling inclusion is "'All You Zombies--" by Robert Heinlein. It makes perfect sense to include something by the grand old man of the genre. But why pick this odd little time-travel story when there's such a wealth of great alternatives? Card could have chosen "The Logic of Empire", "The Roads Must Roll", "The Man Who Sold the Moon", or one of at least a dozen other first-class stories instead.

Overall then, this is a solid collection, with some very good stories by big names in the genre. If only there were more of them.

3/4

Where to find the best science fiction short stories

I recently went looking for some collections of really top classic science fiction stories. Here's what I found.

If you're looking for a single volume, you probably can't do better than Masterpieces: The Best Science Fiction of the 20th Century. The collection covers a broad span of time, includes really big names, and the anthologist is Orson Scott Card, a highly respected author in the genre.

Beyond that, the ways part. The SFWA, the professional association of SF writers, got together in the early seventies and assembled The Science Fiction Hall of Fame, a collection of science fiction masterworks in three volumes, the first covering short stories and the other two covering novellas.

For more recent work, you might try The Best of the Best: 20 Years of The Year's Best Science Fiction by Gardener Dozois. Dozois was for a long time the editor of Asimov's, the top forum of the field for short fiction, as well as the editor of The Year's Best Science Fiction, an annual anthology of short stories. He has collected some of his top choices of more recent material in two volumes, one for short stories and the other for novellas.

And for even more recent material, there is Twenty-First Century Science Fiction, published in 2013.

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.

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.