Discussing Joel’s “The Perils of JavaSchools”

On a undergrad course I was teaching recently, I asked my students to read and discuss a blog article by Joel Spolsky titled The Perils of JavaSchools. In that article, Joel makes provocative remarks against using Java as  the main programming language in introductory Computer Science  (CS) courses instead of more challenging programming languages like C and Lisp. His main point is that “Java is not a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers.” His point is valid, but I found his discussion mostly emphasizes programming in a CS context.The following paragraphs expand some of his points within a Software Engineering (SE) context.

What is a good/great programmer? Joel mentions “good/great programmer” repeatedly, but it does not reveal what he means by a good/great programmer. Being knowledgeable of functional programming, pointers, and recursion? Well, in the software community we say: “A good developer knows that there is more to development than programming, a great developer knows that there is more to development than development”. In SE in particular, industry is interested in professionals that besides being knowledgeable of multiple programming languages and technologies, are capable to produce high-quality software in a disciplined manner. That is to say, to produce self-documented, testable software applying proven design and construction techniques, and a systematic software process. Those are aspects that should be considered when evaluating a programmer.

There are different kinds of programmers. Joel focuses his discussion mostly in CS, in fact he never uses words such as “software engineer” or “software engineering”. Software industry it is too diverse and so diverse are the developers. It requires different skills to develop an operating system or a compiler than to develop  business applications. There are great programmers in both sides.

Academia must be aware of industry needs. The academia has to suffice industry demands for more and better programmers. Many of us are attracted to pursue a career in software engineering because of this demand. In order to satisfy different kind of developers, universities might create different programs (CS, SE, Games, Embedded, Real-Time, etc.) Everyone chooses a given program according to his/her own preferences. The fact that we feel admiration for great programmers like Linus Torvalds (a CS-like developer) does not necessarily means that we want to do what he does… and yet be capable to be good at it.

Understanding recursion and pointers is key. This knowledge definitely shapes problem-solving skills and enhances the ability to produce efficient code. Although, these concepts can be taught in Java, C provides a richer experience. Joel makes a good point when he says that when you get a segmentation fault in C, you actually need to force your mind to find and solve the problem. Similar to the problems we have to solve in those mathematics and calculus courses we are force to take; we may not need to solve a integral equation anymore but those courses prepare our brains for solving problems at different levels of abstraction.

Programming languages diversity is good. It is clear that we need to be exposed to different programming languages. I’m uneasy accepting that there are such academic programs based on just one language.

There is a natural human reaction against a newer and easier experience. When I was learning programming – a long time ago, I know! – using Pascal and C, I still remember old fellows suggesting me to program in the real deal: Assembler. I never did, but I heard a guy claiming that he developed an entire payroll system in Assembler (yeah, right!). Perhaps some of you, products of the Java school, might have similar views to Joel’s regarding the current trend of replacing Java with Python and Ruby in introductory CS courses.

Post a comment

Copyright © TWIMES
The World In My EyeS

Built on Notes Blog Core
Powered by WordPress