Please don't get the wrong impression from this thread. I've been searching for programming jobs lately and the vast majority of them are the sort of thing the blog post is talking about: databases, business rules, and user interface, where the UI is mostly web these days. Note how the posters in this thread who say higher math doesn't get much use are speaking from personal experience, and those promoting it are talking in the abstract. Yes, there are jobs where you need to know advanced stats, linear algebra and calculus, but it's really the minority of programming jobs. And even then stuff like physics simulations are likely to be filled by someone with physics expertise who can also program, rather than "pure" programmers who know calculus. (Bioinformatics may be another story.)

My CS department in college required three semesters of calculus and two of physics. I'd done enough real-world programming by then to know it wouldn't make a better programmer. I did okay, but they certainly weren't my favorite courses. And y'know, I've never gotten paid to use any of that knowledge. I once had a discussion with a coworker about polynomial and exponential functions, but that was so he could draw a particular shape of curve in the UI. Calc and linear algebra have been essentially for learning computer graphics, and I recently got a hand-derive a function to interpolate smooth motion (calculate displacement as the integral of a quadratic velocity curve). But I haven't succeeded in getting anybody to pay me for that stuff.

The best way to find out if you're a decent programmer is to write a lot of programs. It really does seem to be a skill that you either have or you don't, to the extent that people from non-technical backgrounds will wind up falling into programming positions. I know a pretty good developer whose degree is in theater, and great one who dropped out of a biology PhD program. (Though the latter guy may have decent math skills, I dunno.)

So please don't discount a CS degree if that's what you really want. They may have some tough math requirements, but CS curricula are not very in touch with the real world. Even most academic computer science is discrete math, which is quite a bit different than calculus and may be more your sort of thing. That said, I'm not sure any of that will be useful for you if what you really want to do is system administration. (I'm not familiar with the formalities of that job market but it seems to me that the best sysadmins are self-taught, to an even greater degree than programmers.) But if you're considering a career in software development and only switching to sysadmin work because of math, you've got the wrong impression of software development.

Go out and do some open source work if you want a sense of real world programming. And maybe consider a software engineering degree. I'm skeptical of how many software engineering programs are really in tune with reality, but at least they'd probably have less pointless math requirements.

As the parser needs more data, the run-time system will cause hGetContents to read another block. So, here we have an example of a pure function that's indirectly triggering IO, and it's doing it all without violating the constraints of the type system.

Actually hGetContents cheats by using unsafeInterleaveIO. It's a cool hack, but lazy IO is an inherently risk business. For instance, if your program later wrote back changes to your scene file, the result is undefined. There's no guarantee of when the program is done reading the file. If you keep this in mind it's no problem, but if all IO worked this way you'd go insane. (Also consider the problem of error handling if there's a disk error.)

That's how I used to think it worked too, but then I had to modify a universal binary by hand one day. Turns out that the compiler tools are smarter than that.

My recollection is that the layout is something like this (for a PPC32/x86 binary):

• 1. Universal header
• 2. PPC32 Mach-O header
• 3. PowerPC code segment
• 4. x86 Mach-O header
• 5. x86 code segment
• 6. Data segments

Both architectures get positive offsets to refer their data, so they work just fine. Sure the PowerPC Mach-O "file" has a bunch of useless crap in the middle of it, but the Mach-O loader doesn't notice since those byte ranges aren't mentioned in the PowerPC header. Pretty clever.

You can confirm this by running strings(1) on a Universal binary and seeing that there's only one copy of the string constants.

The last two states I've lived in had a section of their income tax forms for paying out-of-state sales tax. If you wanted to itemize everything you bought that year, you could. But I imagine most people pick the option of paying a small flat tax and only itemizing very large purchases. Either way, it's a required section of the state's income tax return. (Though you could of course claim to have made no such purchases.)