Blunting the haters

I’m not the biggest fan of James Blunt’s music, but I have to admit that I am a fan of his responses on Twitter to people who tweet that they aren’t fans either:

UPDATE: Whoops, looks like my Twitter post embedding is a bit broken.  I’ll have it fixed soon.

UPDATE 2: OK, it’s sort of fixed…

Delphi, Java and Visual Basic! Oh my!

Yesterday, MyBroadband published an editorial piece regarding the Department of Basic Education’s choice of programming languages for the high school curriculum (and for the coders who come here, it’s well worth a read).  Specifically, the direction seems to be Delphi — this resulted in a storm of comments describing Delphi as “outdated”, “obsolete”, “antiquated” and similar.  While those are perfectly valid points, there is something important that those commentators have overlooked.

Delphi is an object-oriented derivative of the Pascal language, created in the late 1960s, and what a lot of people don’t realize is that Pascal (and hence, by extension, Delphi) was primarily created as a language to teach students structured programming.  The language lacks features that would make it useful in a commercial/production environment (I certainly wouldn’t use it to pay the bills!), but it’s just fine for teaching basic concepts — perhaps not the absolute best choice (as I’ll go into a little later), but a solid choice nonetheless.  True, it’s not what’s being used out there in the Real World, but as the DBE (correctly, in my opinion) puts it, their aim is not vocational training, but “to lay a solid foundation to enable a learner to pursue further education at [a higher education institution] in the IT field”.  Delphi, Pascal, and several other languages do just that.

This is something that I can most definitely attest to with my personal experience.  I took my first foray into programming with Turbo Pascal, when my age was still in the single figures, and it was the language that I used when I completed high school in 2002.  (We were the last class to use Turbo Pascal though, the 2003 class were on Delphi.)  I have neither seen nor written a line of Pascal code since, but the concepts taught served me well when I moved on to “Real World” languages (C, C++, C#, Java, PHP and plenty of others).  A few years later, when working as an instructor at a private college, I noticed a distinct pattern: the people who had those concepts instilled into them in high school generally handled the subject matter satisfactorily (it was mainly Pascal and Delphi folks filtering though), whereas the people who hadn’t were jumping straight into C#, Java and Visual Basic, and finding themselves well out of their depths.

The last sentence above is worthy of further elaboration and dissection, as a lot of people over on the MyBroadband thread believe Java to be a worthy first language.  I strongly disagree, and I’m not the only one.  In January 2008, Dr. Robert B.K. Dewar and Dr. Edmond Schonberg published in the Journal of Defense Software Engineering a piece entitled “Computer Science Education: Where Are the Software Engineers of Tomorrow?” (freely downloadable as a PDF here), in which Java comes in for some particularly savage mauling (search the paper for “The Pitfalls of Java as a First Programming Language”).  As they brutally put it, Java “encourages the [first time] programmer to approach problem-solving like a plumber in a hardware store: by rummaging through a multitude of drawers (i.e. packages) we will end up finding some gadget (i.e. class) that does roughly what we want”.  There’s a lot of boilerplate code that one has to write in Java around a simple “Hello World!” program: there were a few folks over on the MyBroadband thread lamenting the fact that they had to parrot-learn “public static void Main()” without understanding what “public”, “static” and “void” did and, more importantly, why they were important.  It’s perfectly fine if you have the concepts already and are using this in a production environment.  Not so fine though when you’re learning how to program the first time.

Eric S. Raymond, in his “How To Become A Hacker” essay, makes a point that I find very hard to disagree with:

There is perhaps a more general point here. If a language does too much for you, it may be simultaneously a good tool for production and a bad one for learning. It’s not only languages that have this problem; web application frameworks like RubyOnRails, CakePHP, Django may make it too easy to reach a superficial sort of understanding that will leave you without resources when you have to tackle a hard problem, or even just debug the solution to an easy one.

Having said that however, I have some concerns about the Department of Basic Education’s approach. From the MyBroadband article, it looks like the curriculum will be primarily based on using wizards; I may be a bit old-school, but this approach makes me uncomfortable. To me, it’s just a different type of boilerplate (just a different iteration of “public static void Main()” in a way) — great for production, where time is a factor, but for learning and educational purposes, you want people to know (0) what the wizard is doing, and (1) why it’s doing what it’s doing. Nothing that I read in the original article gives me any confidence that pupils will be taught this.

Finally, while I consider Pascal/Delphi good teaching languages, I don’t consider them to be the best.  That accolade, to me, goes to Python.  From a beginner point of view, it’s cleanly designed, well documented and, compared to a lot of other languages out there, relatively kind to beginners — and yet, the language itself is powerful, flexible and scalable to far larger projects.  Moreover, the language is free (both free as in freedom and free as in beer), which was one of the original requirements of the Department of Basic Education but which seems to have been kicked to the sidewalk at some point.  For those interested, ESR has written a detailed critique of Python, and the Python website itself has some very good tutorials.

Download All The Things, Round II

Those of you who have been reading this blog for a while may recall Download All The Things!, where I investigated the feasibility of downloading the entire Internet (lolcats included, of course).  I’ve decided to revisit this, but with one small (or not so small) difference: change our estimation of the size of the internet.

For Round II, I’m going with one yottabyte (or “yobibyte” to keep the SI religious happy).  This is a massive amount of data: 1024 to the power 8 (or 2 to the power 80) bytes (and no, I’m not typing the full figure out on account of word-wrapping weirdness); it’s just short of 70,000 times the size of our previous estimate.  To give a more layman-friendly example: you know those 1 terrabyte external hard drives that you can pick up at reasonable prices from just about any computer store these days?  Well, one yottabyte is equivalent to one trillion said drives.  A yottabyte is so large that, as yet, no-one has yet coined a term for the next order of magnitude.  (Suggestion for those wanting to do so: please go all Calvin and Hobbes on us and call 1024 yottabytes a “gazillabyte”!)

There’s two reasons why I wanted to do this:

  • Since writing the original post, I’ve long suspected that my initial estimate of 15 EB, later revised to 50 EB, may have been way, way too small.
  • In March 2012, it was reported that the NSA was planning on constructing a facility in Utah capable of storing/processing data in the yottabyte range.  Since Edward Snowden’s revelations regarding NSA shenanigans, it’s a good figure to investigate for purposes of tin foil hat purchases.

Needless to say, changing the estimated size of the internet has a massive effect on the results.

You’re not going to download 1 YB via conventional means.  Not via ADSL, not via WACS, not via the combined capacity of every undersea cable.  (It will take you several hundred thousand years to download 1 YB via the full 5.12 Tbps design capacity of WACS.)  This means that, this time around, we’re going to have to go with something far more exotic.

What would work is Internet Protocol over Avian Carriers — and yes, this is exactly what you think it is.  However, the avian carriers described in RFC 1149 won’t quite cut it out, so we’ll need to submit a new RFC which includes a physical server in the definition of “data packet” and a Boeing 747 freighter in the definition of “avian carrier”.  While this is getting debated and approved by the IETF, and we sort out the logistical requirements around said freighter fleet, we can get going on constructing a data centre for the entire internet.

As for the data centre requirements, we can use the NSA’s Utah DC for a baseline once more.  The blueprints for the data centre indicate that around 100,000 square feet of the facility will be for housing the data, with the remainder being used for cooling, power, and making sure that us mere mortals can’t get our prying eyes on the prying eyes.  Problem is, once the blueprints were revealed/leaked/whatever, we realised that such a data centre would likely only be able to hold a volume of data in the exabyte range.

Techcrunch told us just how far out the yottabyte estimate was:

How far off were the estimates that we were fed before? Taking an unkind view of the yottabyte idea, let’s presume that it was the implication that the center could hold the lowest number of yottabytes possible to be plural: 2. The smaller, and likely most reasonable, claim of 3 exabytes of storage at the center is directly comparable.

Now, let’s dig into the math a bit and see just how far off early estimates were. Stacked side by side, it would take 666,666 3-exabyte units of storage to equal 2 yottabytes. That’s because a yottabyte is 1,000 zettabytes, each of which contain 1,000 exabytes. So, a yottabyte is 1 million exabytes. The ratio of 2:3 in our example of yottabytes and exabytes is applied, and we wrap with a 666,666:1 ratio.

I highlight that fact, as the idea that the Utah data center might hold yottabytes has been bandied about as if it was logical. It’s not, given the space available for servers and the like.

Yup, we’re going to need to build a whole lot of data centres.  I vote for building them up in Upington, because (1) there’s practically nothing there, and (2) the place conveniently has a 747-capable runway.  Power is going to be an issue though: each data centre is estimated to use 65 MW of power.  Multiply this by 666,666, and… yeah, this is going to be a bit of a problem.  Just short of 44 terawatts are required here, and when one considers that xkcd’s indestructible hair dryer was “impossibly” consuming more power than every other electrical device on the planet combined when it hit 18.7 TW, we’re going to have to think outside of the box.  (Pun intended for those who have read the indestructible hair dryer article.)

Or not… because this means that our estimate of one yottabyte being the size of the internet is way too high.  So, we can do this in phases: build 10,000-50,000 or so data centres, fill them up, power them up, then rinse and repeat until we’ve got the entire Internet.  You’ll have to have every construction crew in the world working around the clock to build the data centres and power stations, every electrical engineer in the world working on re-routing power from elsewhere in the world — especially when one considers that, due to advancements in technology (sometimes, Moore’s Law is not in our favour), the size of the Internet will be increasing all the time while we’re doing this.  But it might just about be possible.

That said: even due to the practical impossibility of the task, don’t underestimate the NSA.

Or, for that matter, Eskom:

How hard can it be?

… trying to get from Upper Woodstock to Parklands in good time before the afternoon peak?

Well, if the N1 outbound is closed due to a freak truck accident, very hard.  Instead of cruising up the R27, which should have taken me around 30 minutes, I ended up having to take a rather convoluted route home to avoid the resulting city-wide traffic jam.  Made it home in 90 minutes though.

Of course, it happens on a day that I didn’t ride the bus in to work.  Just lovely.