The one time we try to update things quietly...
EDIT: We are going to post 2.0 tomorrow morning our time (that's about 18 hours from now), but we have setup a redirect from the old dev version that was posted to a newer student version. The dev version shows all comments/planning etc so harder to read. Though everything will look much nicer tomorrow morning with the new open source version hosted here https://github.com/uccser/cs-field-guide
We have pushed through the update, may still be some caching issues. Try loading http://www.csfieldguide.org.nz/ with a clear cache (or in an incognito browser), you should see a page with an indigo background. The Sphinx version is our old website.
I'd say it's in a large part due to him that Python is becoming the de facto standard for high school programming in New Zealand.
He's also a bloody good lecturer, he teaches the intro to algorithms at Canterbury, and does heaps of physical demonstrations of how algorithms work, like using a set of scales for sorting algorithms.
1) I can learn anything I need to when the need comes up
2) With the exceptions of PLT and complexity, there are a lot of things (network protocols, compression, crypto, formal languages) that have not come up yet!
So I'm glad to see a survey of these subjects. Formal languages in particular I've felt the hole.
While the section on grammars is yet to be written, what's there is still one of the less practically useful parts of language theory. It's nice to know how to direct-encode a regex matcher as an FSA using the program counter as the implicit state register, but it's exceedingly rare that you need that level of performance. And that's pretty much the only time you really need to know the fine details of regular language <-> FSA.
However, quite apart from working as a compiler engineer for 7 years or so, I've found formal languages come up quite a bit. Not necessarily regular languages, but ad-hoc languages and parsing issues are very common if you do much work involving data from third parties. I continually build ASTs and AST-like things to solve everything from client-side routing + module systems to ad-hoc query UIs.
It's a great introduction to the fundamentals of many fields of CS and is accessible to all sorts of folks.
I work in a platform team in a large multinational and had to laugh about the XKCD. I also was a bit surprised about the one-sided view presented here to unexperienced readers who might not think ahead. I cannot count the number of times I encountered the other side of the story where each team tells me their code is special, different from everybody else. Costing the company lots of money while all they are doing is reimplementing data storage, authentication, image processing algorithms, or feature X for the 10th time. The surprise on their face when we let our generic platform component handle it for them with just a few lines of code is always priceless (usually after such a demonstration they come shopping and start "aha-ing" when we tell them that other feature they now want for free from us is too specific to have in a platform :D)
My last company threw away our expensive IP and tried to use off-the-shelf platform stuff. They're struggling now, with a product lacking features, performance and scalability. Funny, that's what the platform promised to deliver!
P.S. My computer science class was split between 12 "green screens" and 12 card punch machines. Yes I'm old ;)
Given the right tools, even something as locked down as an Android tablet can be surprisingly effective development tool.
Software developers should not work more than 40 hours per week. If they do overtime one week they should not do more overtime the following week. This helps keep software developers happy and makes sure they don’t get overworked.
I was always getting grounded, parents would take away everything, send me to my room, all I had in there was a Tandy.
The requested URL /Introduction.html was not found on this server.
Or maybe "stop breaking the Internet" is just the new "get off my lawn."