Joel Spolsky writes a very interesting essay about why teaching Java in colleges is actually bad for the computer industry (and for the students themselves). I’ve heard the same kind of thing repeated around halls at Microsoft. Almost every team I interview with my camcorder says they can’t find enough C or C++ programmers to get their stuff done. Some on very exciting teams with hundreds of millions of users. Some that, gasp, actually have budget to hire real programmers. And, this isn’t just a US problem. The problem exists at our offices around the world. Every team I talk with says they wish they could hire more hard-core programmers.
88 thoughts on “Joel says teaching Java is bad for CS students”
Comments are closed.
haha wrong.. java kick ass now
but still its best to know c and c++
haha wrong.. java kick ass now
but still its best to know c and c++
Well, isnt it an interesting conversation….
I still dont exactly know why we are so fixated on languages, but an interesting question remain, how will you teach these aspects of CS if your course uses java as a language of choice?
1. Memory arithmetics.
2. OS programming
3. Memory Management
4. Pefromance Programming
5. Real Networking (low level)
6. Shared Memory
7. Concurrency (including Semaphores and Laches)
6. Macro programming and Heap optimization
And I can list more..
I would agree that once you learned the foundations of CS you can go to any language and be efficient. So, I guess the choice of the language to do real work needs to depend on work, but a choice of the language for learning should not inhibit deep understanding by providing intitive tools.
Well, isnt it an interesting conversation….
I still dont exactly know why we are so fixated on languages, but an interesting question remain, how will you teach these aspects of CS if your course uses java as a language of choice?
1. Memory arithmetics.
2. OS programming
3. Memory Management
4. Pefromance Programming
5. Real Networking (low level)
6. Shared Memory
7. Concurrency (including Semaphores and Laches)
6. Macro programming and Heap optimization
And I can list more..
I would agree that once you learned the foundations of CS you can go to any language and be efficient. So, I guess the choice of the language to do real work needs to depend on work, but a choice of the language for learning should not inhibit deep understanding by providing intitive tools.
Ok, let’s sum it up once again: Joel is sad that he can’t tell good programmers from bad programmers because they have learnt only Java.
In fact he’s aggrieved over his own inexperience with Java.
Let’s repeat an obvious fact: There are things you code in Java, and things you code in other languages (any programmer who knows more than one language probably agrees on this point). Remember, Java is more of a design language than C++; it abstracts away a lot of - arguably - unnecessary issues (like memory allocation and thread locking) and gives you headroom for the higher-level issues, such as maintainability, transparent design, code re-use and documentation (in that sense Java is much closer to scripting languages).
If you want to know a good Java programmer from a bad Java programmer, there are numerous questions that easily reveal the degree of experience of an applicant - e.g. the advantage of using static methods over instance methods, synchronization issues (how do you make sure that a piece of code is executed only once at a given time?), what are the advantages of a given pattern over another, and so on. These things really tell you how deeply a person has been involved with computer programming. And if they grasp those, there’s no reason why they shouldn’t be able to understand pointers or recursion because they have the ability to think out problems in-depth and not on just on a superficial level. I thing that Java is highly underestimated on this point. The problem space is shifted, but nonetheless complex.
Personally I have had to interview some people with a Java background, and I have found it quite easy how to separate the wheat from the chaff.
I think we should clarify two points:
1. Universities don’t teach you how to program. Only industry experience does that.
2. If you need people with C knowledge, don’t try Java-only programmers.
So, if Joel whines about his inability to tell good programmers from bad ones - that’s his problem, and his alone. I wouldn’t mind hiring a Java-only programmer for a Java project, especially if she can answer the above questions.
Ok, let’s sum it up once again: Joel is sad that he can’t tell good programmers from bad programmers because they have learnt only Java.
In fact he’s aggrieved over his own inexperience with Java.
Let’s repeat an obvious fact: There are things you code in Java, and things you code in other languages (any programmer who knows more than one language probably agrees on this point). Remember, Java is more of a design language than C++; it abstracts away a lot of - arguably - unnecessary issues (like memory allocation and thread locking) and gives you headroom for the higher-level issues, such as maintainability, transparent design, code re-use and documentation (in that sense Java is much closer to scripting languages).
If you want to know a good Java programmer from a bad Java programmer, there are numerous questions that easily reveal the degree of experience of an applicant - e.g. the advantage of using static methods over instance methods, synchronization issues (how do you make sure that a piece of code is executed only once at a given time?), what are the advantages of a given pattern over another, and so on. These things really tell you how deeply a person has been involved with computer programming. And if they grasp those, there’s no reason why they shouldn’t be able to understand pointers or recursion because they have the ability to think out problems in-depth and not on just on a superficial level. I thing that Java is highly underestimated on this point. The problem space is shifted, but nonetheless complex.
Personally I have had to interview some people with a Java background, and I have found it quite easy how to separate the wheat from the chaff.
I think we should clarify two points:
1. Universities don’t teach you how to program. Only industry experience does that.
2. If you need people with C knowledge, don’t try Java-only programmers.
So, if Joel whines about his inability to tell good programmers from bad ones - that’s his problem, and his alone. I wouldn’t mind hiring a Java-only programmer for a Java project, especially if she can answer the above questions.
That’s hilarious. Here I sit in Houston with years of C++ experience while working for Shell. That doesn’t even win me an interview nowadays, however. Would-be interiewers never get over the fact that I’m in a power wheelchair.
That’s hilarious. Here I sit in Houston with years of C++ experience while working for Shell. That doesn’t even win me an interview nowadays, however. Would-be interiewers never get over the fact that I’m in a power wheelchair.
Fake trackback here, in which I rip Joel’s arguments to shreds. Jist is: ‘The crux of Joel’s argument about why teaching Java is a bad idea lies in his belief that two concepts, pointers and recursion, are good weed-out concepts, and that you don’t really get either concept in Java, thus you (or basically Joel) can’t ever know if a potential employee is a real computer scientist. The problem with this argument is that there are many other just-as-difficult concepts in computer science that Joel either ignores or doesn’t really know much about, but that are at the core of Java hardcore programming methodology. Joel’s rant, then, can be reduced to, “Teaching students Java is bad because I don’t know Java and its fundamental concepts like object oriented design and design patterns.”‘
Fake trackback here, in which I rip Joel’s arguments to shreds. Jist is: ‘The crux of Joel’s argument about why teaching Java is a bad idea lies in his belief that two concepts, pointers and recursion, are good weed-out concepts, and that you don’t really get either concept in Java, thus you (or basically Joel) can’t ever know if a potential employee is a real computer scientist. The problem with this argument is that there are many other just-as-difficult concepts in computer science that Joel either ignores or doesn’t really know much about, but that are at the core of Java hardcore programming methodology. Joel’s rant, then, can be reduced to, “Teaching students Java is bad because I don’t know Java and its fundamental concepts like object oriented design and design patterns.”‘
What does the language used have to do with anything? Java doesn’t create bad programmers, unless you just don’t like Java.
Java has other advantages as a teaching language that the various members of the C tree don’t, and if Joel thought about it a little, he’d realize that. But language bigotry is as old as computing.
What does the language used have to do with anything? Java doesn’t create bad programmers, unless you just don’t like Java.
Java has other advantages as a teaching language that the various members of the C tree don’t, and if Joel thought about it a little, he’d realize that. But language bigotry is as old as computing.
Sounds like Joel simply likes to recruit in his own image. That’s not exactly uncommon; and probably works pretty well as a recruitment tactic in lots of cases.
Sounds like Joel simply likes to recruit in his own image. That’s not exactly uncommon; and probably works pretty well as a recruitment tactic in lots of cases.
“Um - all of the big websites: Google, Yahoo, Ebay, Amazon, etc are pushing the limits of available hardware TODAY. If you can’t optimize for speed/throughput and do reasonable size/capacity estimates for your software you can’t work in any of these companies.”
It’s always best practice to make the code as efficient as possible. However there are many technologies or tools that are available today to further “assist” in speeding up the software the size of an Ebay for excample. Things like object pooling, message queing, distributed objects and so on. Things that weren’t available back in the day where all they had to rely on for speed was a fast language like C++ using optimised routines and the fastest hardware they could get. I’ve still see many “big” companies who build software with that kind of thinking today and not being aware of the many advances that have been made since.
“Um - all of the big websites: Google, Yahoo, Ebay, Amazon, etc are pushing the limits of available hardware TODAY. If you can’t optimize for speed/throughput and do reasonable size/capacity estimates for your software you can’t work in any of these companies.”
It’s always best practice to make the code as efficient as possible. However there are many technologies or tools that are available today to further “assist” in speeding up the software the size of an Ebay for excample. Things like object pooling, message queing, distributed objects and so on. Things that weren’t available back in the day where all they had to rely on for speed was a fast language like C++ using optimised routines and the fastest hardware they could get. I’ve still see many “big” companies who build software with that kind of thinking today and not being aware of the many advances that have been made since.
“Joel is upset that it is no longer easy to differentiate between programmers of different ability.”
I think that’s a very valid point… but certainly not every Java programmer can get their head around the trickier concurrency issues, so there’s at least one area you could interview on.
Innocent Bystander: agreed that those big systems require that level of skill, but that’s why those companies DO look for the brightest of the bright. But what percentage of jobs (and I don’t know, so I’m wildly guessing) fall into that category? And not all Java people are in the enterprise space, although I certainly acknowledge that’s where Sun threw most of the Java energy for the majority of Java’s life. Some of us where not thrilled with that. But there are 1.5 BILLION Java-enabled devices out there, and less than half of those are desktop machines. Given that the rest are smart cards, cell phones, and other very small environments, there are plenty of Java developers who appreciate that every bit can count.
“Joel is upset that it is no longer easy to differentiate between programmers of different ability.”
I think that’s a very valid point… but certainly not every Java programmer can get their head around the trickier concurrency issues, so there’s at least one area you could interview on.
Innocent Bystander: agreed that those big systems require that level of skill, but that’s why those companies DO look for the brightest of the bright. But what percentage of jobs (and I don’t know, so I’m wildly guessing) fall into that category? And not all Java people are in the enterprise space, although I certainly acknowledge that’s where Sun threw most of the Java energy for the majority of Java’s life. Some of us where not thrilled with that. But there are 1.5 BILLION Java-enabled devices out there, and less than half of those are desktop machines. Given that the rest are smart cards, cell phones, and other very small environments, there are plenty of Java developers who appreciate that every bit can count.
I think most of the comments are still missing the point which Robert touched upon in his comments.
Joel is upset that it is no longer easy to differentiate between programmers of different ability. Once upon a time it was easier to dismiss (I’m making the numbers up) 30% of applicants on the basis they couldn’t handle pointers. You knew this to be the case because every decent programmer would have had to handle pointers at some point during their education (even those who went on to use Lisp or other functional style languages). If you came out the other side and still didn’t have a grip on things like pointers then you could be dismissed as not being able to handle intermediate programming concepts. It was a simple check.
Now you can’t tell so easily. Someone who doesn’t know pointers may simply not know because they were never told and never had reason to use them in anger. You can’t reasonably assume that lack of pointer aptitude means a lack of ability. The correlation has gone and it’s hard to come up with good replacements that test intrinsic aptitude rather than rote learning.
Unlike Paul Graham, Joel is not alleging some programming languages will (directly) damage you or programming language J allows superhuman thought not possible in L. Joel is just saying that Java levels the playing field so well it is hard to tell programmers apart any more.
However I strongly refute that what the world is asking for are people who know C basics (even if it is a differentiator). All the job vacancies want people with specific application skills and domain knowledge not all rounders. Universities are finally bowing to the situation while preserving an extreme split for the purely theorectical.
I was talking to a lecturer at my Alma Mata who was explaining a shift in the used first year programming languages. This was due to pressure in the teaching community, pressure from students wanting real world skills and bizarrely pressure from big companies that were creating internal department demand for people with specific language skills. Tools and their availability have a role in this.
I could go on at length about what I think the causes and effects are (quite frankly I’m surprised that MS would feel the effects even though I personally wouldn’t apply) but at the end of the day *business* doesn’t want C/Lisp skills. They aren’t the measure people who make the descisions use or demand.
I think most of the comments are still missing the point which Robert touched upon in his comments.
Joel is upset that it is no longer easy to differentiate between programmers of different ability. Once upon a time it was easier to dismiss (I’m making the numbers up) 30% of applicants on the basis they couldn’t handle pointers. You knew this to be the case because every decent programmer would have had to handle pointers at some point during their education (even those who went on to use Lisp or other functional style languages). If you came out the other side and still didn’t have a grip on things like pointers then you could be dismissed as not being able to handle intermediate programming concepts. It was a simple check.
Now you can’t tell so easily. Someone who doesn’t know pointers may simply not know because they were never told and never had reason to use them in anger. You can’t reasonably assume that lack of pointer aptitude means a lack of ability. The correlation has gone and it’s hard to come up with good replacements that test intrinsic aptitude rather than rote learning.
Unlike Paul Graham, Joel is not alleging some programming languages will (directly) damage you or programming language J allows superhuman thought not possible in L. Joel is just saying that Java levels the playing field so well it is hard to tell programmers apart any more.
However I strongly refute that what the world is asking for are people who know C basics (even if it is a differentiator). All the job vacancies want people with specific application skills and domain knowledge not all rounders. Universities are finally bowing to the situation while preserving an extreme split for the purely theorectical.
I was talking to a lecturer at my Alma Mata who was explaining a shift in the used first year programming languages. This was due to pressure in the teaching community, pressure from students wanting real world skills and bizarrely pressure from big companies that were creating internal department demand for people with specific language skills. Tools and their availability have a role in this.
I could go on at length about what I think the causes and effects are (quite frankly I’m surprised that MS would feel the effects even though I personally wouldn’t apply) but at the end of the day *business* doesn’t want C/Lisp skills. They aren’t the measure people who make the descisions use or demand.
I think I can agree with that… I spent many years coding in C and C++, and because of my job, I’m just now getting around to Java, and I gotta say, I very much prefer C or C++ for a lot of stuff over Java. Java almost forces you to code a certain way, and with C or C++, I can pretty much code near the edge of shooting myself in the foot if I so desire. C and C++ are the heavy lifters of the programming world.
I think I can agree with that… I spent many years coding in C and C++, and because of my job, I’m just now getting around to Java, and I gotta say, I very much prefer C or C++ for a lot of stuff over Java. Java almost forces you to code a certain way, and with C or C++, I can pretty much code near the edge of shooting myself in the foot if I so desire. C and C++ are the heavy lifters of the programming world.
“How many apps really *need* that extreme, deep degree of problem-solving at the algorithm level? (Especially when so many “hard problems” have already been solved, and the ability to use existing resources is a skill in itself — too many people are out there reinventing the flat tire…)”
Um - all of the big websites: Google, Yahoo, Ebay, Amazon, etc are pushing the limits of available hardware TODAY. If you can’t optimize for speed/throughput and do reasonable size/capacity estimates for your software you can’t work in any of these companies. For these systems to stay up and responsive, developers must constantly optimize their code.
The Java people have been focused on the enterprise internal space pretending hardware is free and size doesn’t matter.
“How many apps really *need* that extreme, deep degree of problem-solving at the algorithm level? (Especially when so many “hard problems” have already been solved, and the ability to use existing resources is a skill in itself — too many people are out there reinventing the flat tire…)”
Um - all of the big websites: Google, Yahoo, Ebay, Amazon, etc are pushing the limits of available hardware TODAY. If you can’t optimize for speed/throughput and do reasonable size/capacity estimates for your software you can’t work in any of these companies. For these systems to stay up and responsive, developers must constantly optimize their code.
The Java people have been focused on the enterprise internal space pretending hardware is free and size doesn’t matter.
Joel is looking for superstars… the brilliant elite that, say, Google is looking for. That’s fine, but two guys with a combined year of semester of college between them are just as likely to change the world with a thoughtful, creative web app cooked up in their garage. How many apps really *need* that extreme, deep degree of problem-solving at the algorithm level? (Especially when so many “hard problems” have already been solved, and the ability to use existing resources is a skill in itself — too many people are out there reinventing the flat tire…)
The success of most products is based far more on design, usability, usefulness, and delighting users. We’d all be in much better shape (as both developers and users) if more CS schools were teaching *that*. Good developers need right-brained creativity as much (or more) than pure left-brained logic, and they need the ability to discover, understand, and deliver what real people need and want, etc. -what Joel describes sounds more like the brilliant scientist working in a white lab coat in a clean room untouched by, say, real customers : )
But I still found it surprising that Joel didn’t mention multi-threading. Developing even a modest multi-threaded app with semaphores, avoiding deadlock, race conditions, etc. isn’t (for most of us) trivial. And there *are* plenty of folks in the “java community” who DO care about scarce resources… cell phones, for example (nearly all of which run Java today), aren’t exactly swimming in them.
I’d love to see a smackdown debate between Joel and Gilad Bracha (Sun’s “computational theologist”), or James Gosling on these points…
Joel is looking for superstars… the brilliant elite that, say, Google is looking for. That’s fine, but two guys with a combined year of semester of college between them are just as likely to change the world with a thoughtful, creative web app cooked up in their garage. How many apps really *need* that extreme, deep degree of problem-solving at the algorithm level? (Especially when so many “hard problems” have already been solved, and the ability to use existing resources is a skill in itself — too many people are out there reinventing the flat tire…)
The success of most products is based far more on design, usability, usefulness, and delighting users. We’d all be in much better shape (as both developers and users) if more CS schools were teaching *that*. Good developers need right-brained creativity as much (or more) than pure left-brained logic, and they need the ability to discover, understand, and deliver what real people need and want, etc. -what Joel describes sounds more like the brilliant scientist working in a white lab coat in a clean room untouched by, say, real customers : )
But I still found it surprising that Joel didn’t mention multi-threading. Developing even a modest multi-threaded app with semaphores, avoiding deadlock, race conditions, etc. isn’t (for most of us) trivial. And there *are* plenty of folks in the “java community” who DO care about scarce resources… cell phones, for example (nearly all of which run Java today), aren’t exactly swimming in them.
I’d love to see a smackdown debate between Joel and Gilad Bracha (Sun’s “computational theologist”), or James Gosling on these points…
Greetings,
Having rtfa, I think it’s pretty clear that Joel is making a point a lot of less-read people have made: Java is an easy language to ‘get mostly right’, and a hard language to ask hard questions in.
That is, it’s not sufficiently deep a language that you can really ask many questions to find out how deep someone has gone in learning the language. You know 95% of what you will ever know about Java within a year of working with it.
With C++ there’s a real distinction between someone whose been professionally programming in it for a year and who has been programming for 10 years.
In C++ you can often tell by talking to people about allocators, the Boost libraries, how MFC broke the MVC pattern it was trying to promote, talking about experiences (usually bad) with multiple inheritance, and of course the everpresent shared laughter about pointer disasters. Strange as it is to say, experienced C++ developers have war stories about this stuff, and you can TELL who they are.
So how do you judge depth of knowledge in Java? Memorization of the API? That’s silly, code completion obsoletes that.
Java has fewer dark holes that all developers will end up going into (thus becoming experienced), so there is less shared context about advanced techniques. You think pointers and recursion are bad? Try reading Modern C++ Design by Alexandrescu. My brain hurts reading it, and I consider myself very good at C++. There’s just no real equivalent dark corners and advanced techniques in Java, is what Joel seems to be saying.
(Don’t take this as dittoing, though, there are places that I somewhat disagree; if you can get a Java developer talking intelligently about concurrency issues they’ve faced with threading and such, you can often get a real gauge of their skills. The same is true, though, about ANY language and threading…
)
I’ve babbled on for long enough, but that’s my take on Joel’s article, more a wish to be able to distinguish experienced vs. inexperienced Java developers, rather than a whining wish return to the old C++ days.
- Morgan Schweers, CyberFOX!
Greetings,
Having rtfa, I think it’s pretty clear that Joel is making a point a lot of less-read people have made: Java is an easy language to ‘get mostly right’, and a hard language to ask hard questions in.
That is, it’s not sufficiently deep a language that you can really ask many questions to find out how deep someone has gone in learning the language. You know 95% of what you will ever know about Java within a year of working with it.
With C++ there’s a real distinction between someone whose been professionally programming in it for a year and who has been programming for 10 years.
In C++ you can often tell by talking to people about allocators, the Boost libraries, how MFC broke the MVC pattern it was trying to promote, talking about experiences (usually bad) with multiple inheritance, and of course the everpresent shared laughter about pointer disasters. Strange as it is to say, experienced C++ developers have war stories about this stuff, and you can TELL who they are.
So how do you judge depth of knowledge in Java? Memorization of the API? That’s silly, code completion obsoletes that.
Java has fewer dark holes that all developers will end up going into (thus becoming experienced), so there is less shared context about advanced techniques. You think pointers and recursion are bad? Try reading Modern C++ Design by Alexandrescu. My brain hurts reading it, and I consider myself very good at C++. There’s just no real equivalent dark corners and advanced techniques in Java, is what Joel seems to be saying.
(Don’t take this as dittoing, though, there are places that I somewhat disagree; if you can get a Java developer talking intelligently about concurrency issues they’ve faced with threading and such, you can often get a real gauge of their skills. The same is true, though, about ANY language and threading…
)
I’ve babbled on for long enough, but that’s my take on Joel’s article, more a wish to be able to distinguish experienced vs. inexperienced Java developers, rather than a whining wish return to the old C++ days.
- Morgan Schweers, CyberFOX!
Wonder what Joel thinks of Perl.
Wonder what Joel thinks of Perl.
As to why theres not enough C++ coders I think has to do with difficulty. I used to remember students dropping halfway into the semester when it came time to learn pointers. Even moreso when it came to data structures. As to wether knowing C++ makes one a better .NET programmer, the answer is - it depends. C++ (or C#)is a language while .NET (or J2EE)is really a framework or libary. One uses the language to glue together different parts/components (ADO.NET, ASP.NET etc) of a framework to form a solution. These days its not enough just to learn the syntax or OO techniques from a language like C++ or Java but to also understand the many libraries out there that are available to make your life easier and more productive.
As to why theres not enough C++ coders I think has to do with difficulty. I used to remember students dropping halfway into the semester when it came time to learn pointers. Even moreso when it came to data structures. As to wether knowing C++ makes one a better .NET programmer, the answer is - it depends. C++ (or C#)is a language while .NET (or J2EE)is really a framework or libary. One uses the language to glue together different parts/components (ADO.NET, ASP.NET etc) of a framework to form a solution. These days its not enough just to learn the syntax or OO techniques from a language like C++ or Java but to also understand the many libraries out there that are available to make your life easier and more productive.
Wow, it seems like most of the comments missed the point of the article. It seemed like what Joel was expressing was how he measured new candidates for hire. To him, Java takes away the pitfalls of programming. Of course it does! That was part of the bedrock of Java’s (and C# and .NET and Delphi and all the scripting languages) design. What he is lamenting about is the lack of knowledge being passed along.
If I were Joel, I’d be less concerned with the languages, and *MORE* concerned with the tools. Recursive algorithms are very cool, but how many colleges have classes in Debugging? I don’t care WHAT language you use, being able to step through code and being efficient at seeing state is MORE important than the language. Don’t get me started at how few ‘REAL’ developers don’t know how to use source control…
I guess it comes down to fundamentals. What does one person consider fundamental? Joel see metaprogramming as a fundamental. Someone else may see business knowledge as a fundamental. Others may want environment knowledge as a fundemental. Personally, I’d want to hire people who had it all .