Project lead here: We are about to push v2.0 live, apologies if the site goes down momentarily.
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
Is the older version of the site available anywhere? I actually prefer the larger text and greater use of screen width. The 2.0 version of the site is a bit hard on the eyes for me (feels cramped and small).
Thanks Kinnard! We had been using the Sphinx documentation engine to produce the version linked. We have spent the last year writing our own static site generator system alongside making the whole website open source. We are very happy with the result and looking forward to supporting more languages and curriculums soon.
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.
Tim Bell (who helped make this) is a great guy, he spends a lot of time getting kids interested in Computer Science, with CS Unplugged [0], as well as teaching teachers how to teach computer science to high school kids.
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.
This is great! I'm one of those self-taught programmers who holds two truths in his head at once:
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.
The chapter on formal languages is almost entirely about the mapping between regular languages and finite state automata.
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.
I think 3 years ago this would have been super helpful to get to a point where I could know what I don't know. Although it will likely still be helpful in that way now.
It's not nearly as thorough as this site, but I'm reminded strongly of 'The New Turing Omnibus', which has been on the Cambridge (UK) Computer Science pre-undergrad reading list for many years: http://blog.codinghorror.com/practicing-the-fundamentals-the...
It's a great introduction to the fundamentals of many fields of CS and is accessible to all sorts of folks.
"YAGNI stands for “You ain’t gonna need it” and tells developers to keep things simple and only design and implement the things that you know you are really going to need. It can be tempting to think that in the future you might need feature x and so you may as well already create it now. But remember that requirements are likely to change so chances are that you won’t need it after all." [0]
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)
I was with you until the parenthetical remark, which seems to contradict the point. Platform software is great for getting 80% of the way there; then you can be screwed.
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!
I think there is a difference between in-house developed platforms and platforms bought externally. Apart from that, if that 80% is of high quality and suits your needs doing the last 20% yourself is of course the idea. A platform can't give you 100% as it isn't tailored to your specific needs as a product. It shouldn't be in the way for the last 20% that's what a great platform should be. Kick-start you for 80% and not be in the way for the last 20%.
My HS CS class included learning about coaxial Ethernet cabling and dumb terminals (yes, actual amber screen Wyse terminals). I graduated high school in 2002.
There are, at least, things like Termux (https://termux.com/), on Android. Just for laughs, I've been doing actual work (using git, vim, and Go) in Termux on my Nexus 10. Only two things got in my way: screen size and the inability to have a browser and terminal on screen at once. What's particularly sweet about Termux is that it has an APT-based package manager.
Given the right tools, even something as locked down as an Android tablet can be surprisingly effective development tool.
Windows had an msdos assembler preinstalled, last time I checked, which was before vista. Now the 16bit support was removed, but edge comes with a javascript engine, right?
With asm I referred to the OP, the javascript engine bit could relate to the chrome developer tools a chromebook should sport or to sites like jsfiddle, codepen, the msp430 challenge at microcorruption.com, etc. etc. I tried to concur with you, basically.
Really good material here. Particularly liking the dry humou?r here:
-----------------
Programmer welfare
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.
This is awesome! I wish I learned to code during high school. I can't imagine what level the next generation engineers/developers will be like if they start when they're teens. Limitless potential!
Many of us now in our 40s started on Commodore 64s, Atari 800s, Apple IIs and similar when we were actually preteens. I think starting relatively young is pretty normal for every generation of programmers actually.
Bit before my time, but that's probably true enough. The big difference is probably accessibility; there are so many less barriers to entry at this point, it seems like people are starting earlier than ever.
Great info, presented in a nice way. I could not imagine my high school self being the slight bit interested in it. I wish that wasn't the case, because I could've been Mark Zuckerberg had I been interested in CS in high school during the late 1990's/early 2000's.
Hi Dang, I'm Jack (Project lead on CSFG) see my earlier comment about updating to 2.0 today. We wanted to switch the traffic to the latest version of the guide instead of the old one linked. All you are missing out on seeing is all the broken sections :)
I love the concept and the goal, but the irony was too much. Right in the introduction, where it is talking about how speed (as an example of program quality) impacts usability, the little calculator widgets don't work for me (iPad mini, 1st gen, with up-to-date iOS, stock Safari). Maybe it is my hardware or my OS, or my browser, but I'm just a dumb user, so I don't know or care. But maybe they just tried to be too fancy and shot themselves in the foot. Or maybe I should just follow their advice and download Chrome. Yeah, I'm sure the answer is to add another browser to my device and let Alphabet spy on me too (bad enough Apple does it, why give them an advantage).
Or maybe "stop breaking the Internet" is just the new "get off my lawn."
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