-
Website
http://www.scobleizer.com/ -
Original page
http://scobleizer.com/2005/12/29/joel-says-teaching-java-is-bad-for-cs-students/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
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.
I wonder if programmers who've done things in C make better .NET or Java programmers?
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.
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.
http://www.livejournal.com/users/jackwilliambell/
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 =)
The idea that someone well up on a language can't tell another good programmer in that language is a bit weak.
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.
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 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 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.
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.
"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 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.
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 .
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!
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...
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 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 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.
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.
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.
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.
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.
but still its best to know c and c++