Joel says teaching Java is bad for CS students

Well said Andrew. Ditto.

Strange. I have been working in "hard-core" languages (at companies that you might have heard of;) for years and I am dying to get out of it. I am sick and tired of the crap that C/C++ forces you to do. And I am sick of self-important folks like Spolsky talking about how this language or that technology isn't sufficiently "hardcore" for him. I have met several shitty programmers that are only "proficient" in C/C++. And some of the best in the biz right now are in alternate languages. Hell, one of the best programmers I know is working on a large Python project right now, and I can promise you that he could code rings around Spolsky in any language Joel wants to bring to the table.

Yeah and everyone who doesn't program in assembly language is a wimp. I have no idea what a hard-core programmer is when what you're actually asking for are more C programmers.

I'm starting to get why Ray Ozzie has his work cut out for him, obviously real men use pointers, not any of that fuzzy higher level stuff.

Andrew and Mark: actually we've been hiring a lot of .NET types too lately and many of our newer projects (like Microsoft Max) are done wholly in .NET too.

I wonder if programmers who've done things in C make better .NET or Java programmers?

If Microsoft thinks Java is not a language used by "hard-core" or "real" programmers then why did MS invest so much resources to clone it? Was C# a waste of time?

At least in Europe, there are almost no more c/c++ projects. In my daily project offer email, c/c++ has almost disappeared. The very few left over projects are writing device drivers and porting projects (from c++ to java or c#)

scott: last I noticed you can't write Windows' kernel in .NET. Sorry. That doesn't mean .NET isn't useful for a whole range of things. And, many of our big projects have been done in C/C++ and aren't going to be ported to .NET anytime soon (Internet Explorer, most of Office, most of Windows, most of the games, etc).

In answer to your question as to whether C/C++ makes one a better .NET programmer, I am not sure. Certainly, having an underpining knowledge of how heap management works would make one a more efficient .NET programmer, but an intricate knowledge of the minutiae of C/C++ can hamstring a .NET programmer. Who cares if I know what trigraphs are? Or the difference between a OLESTR and a BSTR? It is all busllshit that is abstracted out now with .NET and that is a GOOD THING.

The only thing that C/C++ is good for now is managing legacy code that is either too damn big or too damn brittle to change. And who wants to do that? If the choice is between building something from the ground up in a modern language or once-a-quarter service packs in code that is 10+ years old, that is a no-brainer.

"And some of the best in the biz right now are in alternate languages. Hell, one of the best programmers I know is working on a large Python project right now, and I can promise you that he could code rings around Spolsky in any language Joel wants to bring to the table."

This brings up a very good point. When you're teaching programming to CS students, the language you use is almost secondary. It's the ideas, techniques and concepts that are the most important lesson to be learned.

Why is Java so popular? Well, it's a 'modern' language, it can be used on just about any platform and it helps cover a lot of programming basics. A student well-versed in Java should be able to jump to any other language he or she pleases with relative ease. At Johns Hopkins, my alma mater, I think they take the right path - teach Java at the beginners level and switch over to C/C++ for the intermediate level.

#1 in my http://del.icio.us/BillyG/school folder, guess I'll have to show them that on Tuesday, thx, maybe now they'll listen!

I think what Joel Spolsky is getting at is, there is a greater need of developing problem solving skills of students by introducing them to different languages, thought processes and philosophies. Learning computer science concepts from "Structure and Interpretation of computer programs"(SICP) using Scheme; machine structures from "Computer organization and design" using VHDL and C; data structures from "Introduction to Algorithms" accompanied by K&R's "The C Programming Language" at Freshman/Sophomore level will open up your mind in so many different ways than a student who only knows the JAVA way of doing things. Joel Spolsky's article is not about C programmers being better than Non-C programmers, its about increasing the quality of Computer science education. It doesn't matter if you use C or SQL or BASIC, what matters is that you are using the right tool for solving the problem and you can only learn this if you KNOW that JAVA is NOT the only way.

I say Joel is so right that he is wrong. Details here:
http://www.livejournal.com/users/jackwilliambell/

No programming language is good for all situations. Like most everything else in engineering, somebody who understands how to use the right tool for the right job is more valuable than, in this context, a buffet-style programmer whose depth of programming does not extend beyond the current flavor of the week.

Instead of colleges teaching CS students a particular programming language, colleges should instead allow students to code assignments in any language they want. As long as the end result of the program fulfills any specifications and guidelines of the problem at hand, the language used should not matter. I think many colleges today tie students down to one particular language without exposing them to other languages unless they are forced to in job situations.

Only an intro course on programming fundamentals should enforce a single language to give all students a good starting point. In my case, it was Scheme (6.001), and for all its faults, knowing Scheme actually helped me to learn new languages faster. For example, I and many of my peers were able to learn Java in under a week for a software engineering class.

Most students who understand how to think like a program when approaching a problem can easily pick up a new language such as Java or C# quickly. Once you get the idea of programming down, most languages only differ in terms of syntax and some clever hacks and workarounds.

Instead of focusing too much on which programming language somebody knows, companies should instead ask how quickly a potential intern like me can learn a new language instead. I'm fairly certain an excellent Python programmer, given a few days, can become an excellent programmer in Java or any .net language.

Cheers!
Kirupa =)

Robert: Better than good programmers who've done the same things in .Net or Java? I wouldn't think so. A good programmer is a good programmer, Joel is having trouble working out what exactly a good programmer is beyond his C comfort zone.

The idea that someone well up on a language can't tell another good programmer in that language is a bit weak.

Jack: ahh, excellent points! And what hiring managers are hoping for are the stars. Maybe I should call them stars instead of "hard-core."

"I wonder if programmers who’ve done things in C make better .NET or Java programmers?"

I'm personally trying to obtain a solid understanding of lower level languages so that I know the consequences for my actions at a higher level.

In my university (University of Waterloo), it's Java first year and C/C++ thereafter, which I think is a good thing.

Jeff Atwood and I had a back and forth about this topic a while back.

http://www.lazycoder.com/weblog/index.php/archi...

http://www.codinghorror.com/blog/archives/00027...

I agree with Joel a little bit, but I think that the concepts are more important than the languages. I think that using Java is an excellent way to get the students to focus on good design and architecture, but that eventually it's good for a programmer to understand what's going on under the hood.

I don't think teaching Java is a mistake. However I think schools like the University of Rochester where I studied have it right. They start you off with Java but later expand into C/C++ and general programming paradigms. Then you can diverge based on interest - LISP for the AI people, etc.

I think it's a shame when college grads *only* know Java and haven't been exposed to anything else. It's not that they should be C# or C++ wizards, but that they should understand the basics and be comfortable with the fact that pretty much any algorithm they write is going to end up working pretty much the same in any language.

What's a lot harder to find, and always in demand around here, are programmers proficient in COM, Win32, and ATL programming. You don't get that at universities - you mostly get Unix and STL at best.

I'm back at university for 8 months finishing a degree after being in the real world for 10 years. And other than the intro courses in Java, most of the comp sci courses offered are language agnostic, use languages that make sense, or dont use a programming language at all. The AI courses teach lisp and prolog, operating systems and graphics courses use C/C++. Algorithms in Pascal. Object Oriented Programming in Java. Graph Theory used a pencil.

I think once you get into the 3rd and 4th year courses, they arent teaching you how to write program anymore, they are teaching you how to solve problems.

A number of things struck me as a non-geek thinking about the implications of this situation:

1. I don't recall seeing any mention of AJAX - interesting to say the least.
2. If as seems the case, C++ teaching is on the wane yet MSFT needs those skills, what does this mean for future code maintenance? Is it bad enough to qualify as a skills crisis?
3. One of the most intractable problems I've been told about is about being able to navigate between different code bases. Is this likely to create issues for forward development of new product versions?
4. I've heard so many definitions of .NET, I'm wondering what Robert is referring to here and its relevance to the issues. (If this is a monumental statement of ignorance then fine, educate me please)

As an aside, I was talking this evening with a 30+ years' experienced chap whose name would be familiar to many. He's getting to grips with AJAX and finding there is little out there of any substance that helps in developing his product.

So to at least one person's comments - it seems a good programmer is exactly that. Someone with a penchant for code. In which case, MSFTs quest should not be for C/C++ folk but rather people who are 'good programmers.' From everything I've learned - and I'm sure to be corrected in some measure - 'good' programmers revel in solving hard problems.

I can't imagine a bigger challenge than solving some of MSFTs apparent issues in that regard.

But then it also seems that good folk want to be at places that mirror the attributes currently espoused by GOOGs HCM policies. That looks rather tougher for MSFT to answer than presenting a good business case for new hires.

did u read his other comment Scoble? :

"The very fact that Google invented MapReduce, and Microsoft didn't, says something about why Microsoft is still playing catch up trying to get basic search features to work, while Google has moved on to the next problem: building Skynet^H^H^H^H^H^H the world's largest massively parallel supercomputer. I don't think Microsoft completely understands just how far behind they are on that wave."

what do u think?

on topic: for the most part Joel is right...I started off with C/C++ in university and then it took me one course to learn Java in the following year...it's definitely I guess *trivial* if u go the C++ -> Java route...

As is teaching C#, or C++. They are all crap languages designed by people ignorant of industry history with no taste. I agree with Joel to some extent (although his assertion that MIT produces decent developers rings false based on a number of candidates I've seen there).

As a former uber developer who is now a hiring manager I definitely agree that anybody who tends to refer to himself as a "java developer" will probably fail the tech interview big time. Java has a bunch of libraries that hide a bunch of inefficiencies and complexities and nobody in the Java community has ever worried about scarcity of machine resources.

This means these people can't analyze an algorithm for complexity and haven't the first idea what it means to optimize for either space or speed. They only know one language and thus have only one viewpoint on how to write code.

C# developers will be no better. The key seems to be to look for people with a decent spread of different languages and environments. These people can adapt and have many viewpoints.

The problem is not so much the language used as the way the early CS courses are taught. You can teach a first course using C and not cover recursion and pointers. Trust me - I have. But it is not a good idea. The courses that do a good job using Scheme (look at courses at Northeastern and MIT for example) work not so much because of the language (they use Scheme) but because of the teaching methodology. They have a world class researcher teaching the first CS courses at Northeastern. And he's a good teacher as well. A lessor teacher can use the same tools and do a poor job. Some of my old students are willing to name names on that score but I'll refrain. There is a lot involved in teaching early CS courses but few universities put their best people on it. Carnegie Mellon does BTW. There are some others. But at a lot of schools that role falls to the low person in seniority and they really want (and need for tenure) to focus more of their energy on research. I'd like to see MS Research put some people and money into the whole area of teaching CS 1 through CS 3. We can and need to do better.

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 .

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.

Wonder what Joel thinks of Perl.

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!

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...

"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.

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 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.

"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.

"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.

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.

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.

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."'

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.

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.

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.

haha wrong.. java kick ass now
but still its best to know c and c++