Difficult v Hard as opposed to Java v C
December 31, 2005 | co.mments
People seem shocked, just shocked, about Joel Spolsky's post "The Perils of JavaSchools" because Java is deemed too easy. Spolsky's being quite specific tho', insofar as the post is not a criticism of Java at all, but a concern about the content of CS curricula, where he compares C and java as teaching languages and ends up favouring C.
"Instead what I'd like to claim is that Java is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers."
Which makes me wonder if people read it clearly. Joel calls out two aspects that might discriminate good and bad programmers, recursion and pointers.
"If I may be so brash, it has been my humble experience that there are two things traditionally taught in universities as a part of a computer science curriculum which many people just never really fully comprehend: pointers and recursion." - Joel Spolsky
As I recall there's a pit of despair when you first hit pointers. My C lecturer, Dimitris, even drew the learning curve for us at the beginning of the semester - the middle third looked like a market crash. Some books can help with the concepts, but pointers are... alien. Recursion is another matter. Understanding recursion seems to come down to how it's taught and explained rather than talent.
Joel goes on to say:
"There's nothing hard enough about Java to really weed out the programmers without the part of the brain that does pointers or recursion."
So what's more more interesting here in terms of education than either language wars or the relative merits of languages in the industry is whether Joel is picking the right challenges. I wonder if pointers and recursion are the right hard stuff to be teaching programmers with - I have my doubts. Consider concurrent programming - that's hard, it involves coordinating actors as well as the usual data structures and behaviour issues. I'm fairly sure it's hard in Java*, but Java through its memory and threading model allows you to focus on concurrency with a minimum of incidental noise (such as pointers). Distributed programming is hard (and with it comes the truly hard matters of cache invalidation and naming). Organising medium to large scale software is hard. Yet, Java, the easy language by comparison it seems, gives you plenty of teaching options on these fronts. Joel has a crack at teaching OO but OO is useful for teaching one thing - state - that is, how programs can function with respect to time. The problem with OO, these days, is that if you're going to be working anywhere near a network (these days, lots of us are), it's maybe teaching you the wrong lessons about how to manage said state.
Anyway. Yes, pointers might be hard to fathom except for a tiny fraction of the general population and a small fraction of programmers, but they're arguably an irritation rather than anything fundamentally challenging.So given the educational context, perhaps such annoyances are worth forgoing so you can move students towards hard, as opposed to difficult matters. Joel mentions the SICP material for MIT, which is telling. One of the reasons SICP teaches with Scheme is because in an education setting Scheme has precious little by way of distractions, allowing students and teachers to focus on what's actually being taught. Indeed Scheme seems to be sufficiently clear that you can use it to teach classical mechanics and dynamical systems as well as programming.
* Maybe 10 years from now, someone will be complaining about Erlang not being any good for weeding out mediocre concurrent programmers the way Java was.
December 31, 2005 01:10 AM