![](https://csdnimg.cn/release/download_crawler_static/9174319/bg14.jpg)
xxiv
■ INTRODUCTION
really seen as relevant or interesting. This in turn means that not only are fewer people getting excited by
computing itself, but even less people think that there’s more to it than double clicking an icon.
This problem has drifted up through schools and into universities. Teaching programming is a relatively
challenging task. It requires a certain way of thinking that for many people is tough to get a handle on.
Traditionally universities would start a computer science course by teaching about logic gates, how memory
works and how to program a CPU. Only once you understood what the bare metal was doing would you try
to learn C because although C is a higher level language, it reflects the hardware it runs on. Understanding
the hardware makes understanding C that much easier.
But with larger class sizes, more limited teaching time and students arriving with less and less
knowledge of computing fundamentals, universities have had to adapt. Rather than teaching all that low
level stuff, now they teach Java and scripting languages such as Python. Because these languages handle
all of the fiddly bits for you, you can effectively pretend that they don’t exist (although this can cause some
issues, see “The infinite memory myth”). This is simply fantastic from a productivity point of view, but when
you do want to take it to the next level (maybe you’re processing data and your script is just too slow) you
have no idea where to turn. Worse, when someone tells you the technique for improving that performance,
you have no idea what they’re talking about.
Of course not all universities have taken this route. I’m studying at the Hong Kong Polytechnic
University and their course on Computer Architecture is very detailed and covers a lot of ground. If you
want to get the top grade you will need to implement a CPU cache for the CPU simulator program. Needless
to say, there is a lot to learn for everyone on this course. That said, we need more than this. It’s too late to
capture people’s interest when they’re starting graduate studies. I taught 7 year olds how to program BBC
BASIC when I was in my last year of primary school (they even got presented certificates by the school) and
they loved it. Computing lets you create a virtual world with your mind (they liked to create little text based
adventure games) and ultimate power rested in their hands. They got creative, they added spells, new roads,
secret entrances and much more. Okay, they needed a helping hand (they were only 7) but they had the
desire to create and to build cool new things.
INFINITE MEMORY MYTH
Over the years I’ve done a lot of consultancy work with large enterprise customers and that has inevitably
meant I’ve come across Java on many occasions. One of the interesting things I have come across is
what I’ve termed the Infinite Memory Myth. This seems to crop up more in Java applications than in other
languages, but that’s probably because Java tends to be more widely used in those settings.
The short version of the myth is that developers seem to constantly create new objects, often to the
point where the application consumes huge amounts of memory or crashes altogether. They tend to
have no idea how much memory each object takes or more worryingly why they should care. As far as
they are concerned, they request a new object and one is provided. When an object is no longer used
(i.e. nothing points to it any more) Java will at some point get around to cleaning it up (called garbage
collection). All of this is automatic; the developer doesn’t need to do anything.
The problem is this leads people to forget (or in many cases were never taught at all) that memory is
finite and at some point it simply runs out. You can’t assume that you can read in every row in a table
and that it will always work. You can’t assume that just because your test file is 50MB in size that the
application will never be given a 5,000MB file to work on.