« Watch that space | Main | LaundryList APIs »

Difficult v Hard as opposed to Java v C

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


Keith Gaughan
(December 31, 2005 12:50 PM #)

I think Chris Baus hit the nail on the head when he pointed out in his blog that what recursion and pointers have in common is that they're both forms of indirection, and an understanding of indirection is an essential ability of any half-decent dev.

That, and it's not really pointers as such that screw people up in my experience, but pointer arithmetic.

Also, is Java's concurrency model really something we want to be teaching students? I'd argue that it's not just threads we need to be teaching them, but asymmetric coroutines, actors, and so on. I'd argue tha the likes of Erlang and occam are far superior vehicles for teaching concurrency than Java will ever be.

Keith Gaughan
(December 31, 2005 12:56 PM #)

And, how could I have forgotten, Petri nets, which nowadays seem to be relegated to RTS classes.

(December 31, 2005 11:55 PM #)

Concurrent programming is best left out of a programmer's toolkit unless he's certain to be an OS programmer. So 99.9% of developers shouldn't be aware of anything about the details of concurrency. To that end, most languages should not include explicit concurrency primitives.

Reason for my belief is that 99.999% of developers neither need nor can use concurrency effectively - instead they will invariably botch its use. Better to leave it out.

(January 1, 2006 02:29 PM #)

Maybe that's why we would need concurrency, to get rid of all the less then mediocre programmers.

Bill de hOra
(January 1, 2006 05:25 PM #)

"Reason for my belief is that 99.999% of developers neither need nor can use concurrency effectively - instead they will invariably botch its use."

Perhaps that's because it's not being taught? In other words, perhaps this is something of a circular argument.

christopher baus
(January 2, 2006 05:51 AM #)

> Concurrent programming is best left out of a programmer's toolkit unless he's certain to be an OS programmer.

I disagree. Any application which does a significant amount of I/O is going to have to deal with concurrency. Web apps are concurrent apps.

Keith Gaughan
(January 2, 2006 08:03 AM #)

Any nontrivial consumer application involves concurrency of some kind. And Chris is right: webapps are a very visible and very significant example. And what with multicore processors becoming more prevalent, the ability to competently deal with concurrency is next to essential these days.

(January 3, 2006 08:51 AM #)

Teaching concurrency in Java is a bad idea, IMHO. Effective concurrency comes from not using shared state, and in Java it is based completely around shared state.

Doc McClenny
(January 6, 2006 04:19 PM #)

Pointers! We don't need no stinkin' pointers!

Why not pick punched cards? Assembly language?

Are pointers important anymore? Who really uses recursion? Using these as a proxy for how well someone is going to be at real world programming seems silly and there must be better markers for ability than this.

The problem with teaching CS is that a lot of the hard real-life challenges are also hard to teach, either conceptually or in programming projects.