Wednesday, 4th January 2006
Just outta Java School
The latest article by Joel Spolsky on The Perils of JavaSchools touched a chord and it almost seemed like Joel was taking words out of my mouth. Having just graduated from one of those schools in the US which would qualify as moving towards a Java School, i am in an excellent position to relate to the issue. And i must admit i agree with the opinions voiced by Joel in the article almost in its entirety. There are however a couple of observations i wish to highlight in my latest blog post.
First of all, before i left for US shores, i was a total C/C++ programmer and hated java to the core. The only languages i knew were essentially C,C++ with a smattering of Perl and VB. Now almost a year and a half down the line i am a total java guy, I eat, sleep and breathe java and most of the job openings i apply for are java related. In essence i consider myself to be primarily a java developer. This change of mindset was brought about by the fact that most of the coursework i undertook was primarly java-oriented. In fact during the early phase of my program, i forced myself to do the programming assignments and projects in java when given a choice of languages to choose from, just so that i get competent in java.
Coming to the points i agree with Joel on
There's nothing wrong with Java as an implementation language
Many schools use a lot of different languages in their curriculum, OS design in C, systems design in ASM, Artifical Intelligence in SCHEME or LISP, OO in Java, etc. It's not the language that matters, it's the topics covered. I think you should select the language according to what you teach. If you teach AI or functional programming, then you choose LISP (or Scheme). If you teach UI design, then you use C# or (yuck) VB. If you teach OOP then you use C++ or perhaps Java. The language you choose makes it easier to think in the appropriate domain while removing unneccessary ballast. For instance there is little use teaching networking in Java and C# where socket programming is all of couple of lines of code, as opposed to doing it the Berkeley way using C on Unix. I would hope that CS graduates did not only learn a single language in college. I realised early on during my program that to survive the program I had to learn java, so that's what I did. I found out that it was powerful in different ways. I couldn't overload operators and do cool feature stuff any more. I couldn't write certain stuff by hand because it was faster. Instead, what was considered important was writing stable, non-repetitive code. What happened was that I stopped thinking about efficiency (on a low level, there are still some high level efficiency things I think about when I write database queries or use a whole lot of memory). Instead, I thought about robustness and libraries. Did I really need to write something myself, or was it already in the standard java library ? In short, because I switched from C++ to Java, I stopped thinking about low level efficiency and started thinking about the robustness and ease of reading or my code. I still had to learn C++ later, but I program in C++ now far differently than I did when it was my primary language. It forced me to think about problems and programming in a completely different way. The experience was important for me in terms of understanding what could be done with functional programming. Here is a simple grouping of languages. Once you know a language from each of the core groups Low-level: C, C++ - preferably both Enterprise level: Java, C#, Prototype level: Python, Ruby, Perl, PHP, Functional: Haskell, Lisp, Scheme, Prolog you can pick up any language in a matter of days. The whole point is .... Don't be a one-trick pony.
Two things traditionally taught in universities as part of computer science curriculum which many people just never really fully comprehend: pointers and recursion
During the various courses i took, i came across and had the misfortune of working with a diverse set of CS students as project team members. One of the observations i came across was that students who were java schooled from the beginning had a lot of difficulty with computer science basics such as memory allocation, operating systems, memory management etc (in essence the same issues as pointers and recursion). Here is a classical example. During a certain time of the semester i was working alongside several classmates on two projects from different courses at the same instant of time. One was developing a user level thread library (using C) while the other was a distributed bridge playing game (using java and RMI). My observation was that java bred students failed miserably on the thread library while they did reasonably well with the RMI application. They were able to work with a certain degree of efficiency when working at the higher levels of abstraction that java and RMI affored them and just totally failed to comprehend activation records, stack pointers and base pointers needed when doing stack management and manipulation.
Another issue is difficulty in debugging. The user thread library we had to develop(on Sun Solaris and Linux) would often leave you with a Segmentation fault message whereas the worst the RMI application would scream at you is a Null Pointer Exception splashed across the screen. Very few understood that they are essentially caused by the same problem of dereferencing an invalid memory address. And even fewer were inclined to fire up gdb to debug the Segementation fault bug while they were more than thrilled by the information provided by the stack trace of the java exception. It just made debugging a whole lot simpler for the java bred programmer.
Hence i totally agree with Joel's observation that - "You used to start out in college with a course in data structures, with linked lists and hash tables and whatnot, with extensive use of pointers. Those courses were often used as weedout courses: they were so hard that anyone that couldn't handle the mental challenge of a CS degree would give up, which was a good thing." I have seen it before my very own eyes.
CS schools have allowed their programs to be dumbed down to the point where not only can't they produce working programmers, they can't even produce CS grad students who might get PhDs and compete for their jobs
Considering how hard it would get to stay techinically upto scratch in the fast paced world of technology advancements (and it gets harder with age and commitments), i have often considered teaching as a possible career option. I consider teaching in the US to be a lucrative profession and have often been encouraged by the professor whom i was a research assistant of to pursue a career in teaching. If only i can get my dumbed down java schooled brain to go through the rigours and frustrations of a PhD (the near minimum requirement for a professor) !!! .. well maybe someday. Ok Ok enough day dreaming, get back to the issue which is the Great Java Shift.
One of the reasons i can see why CS curriculum is java oriented is the ease of grading. Believe me grading can be a pain and when given an option of grading assignments in a language such as java as opposed to C/C++, anyone would pick the former. Why ever would you want to worry about library version conflicts, makefiles, compilation errors and other dependencies (not to forget DLL Hell) when all you need to do is put the following line at the end of the assignment handout. "All programs must and will be compiled and run using Java SDK version 1.xxx". Students will dutifully go the Sun's website, download the beast of a runtime and SDK and go about doing the assignment without a whimper. The worst they need to worry about is proper execution of a couple of ant scripts and ensuring the neccesary classes are in the classpath. Besides the ease of submission, the subsequent evaluation of an assignment/project submitted as a jar file as opposed to ReadMe files with multiple folders and multiple make file targets proves a point in in itself.
Having taken courses under various professors and also worked closely with a couple of them, i have come to understand the mindset of teachers and the workings of an academia environment. Joel is spot on when he points out the insecurities they face cause them to encourage dumbing down of coursework.
One of the pros of exploring a career in teaching Computer Science is that apart from the huge demand for it, there will always be a need to teach the basics. Despite all the advances in software technologies with application frameworks such as .Net, J2EE and CASE tools such as Rational Rose etc, any software developer worth his salt will admit that he would be naked without his knowledge of how the basics of computers work. Basics topics such as operating systems, compilers, system software, data structures, algorithms (meat and bread of any CS course) have to be taught. One the other end of the scale are courses that deal with OOP concepts, S/W methodlogy, enterprise Java, .Net etc. The latter mentioned courses target the industry and aim at churning out industry ready developers while the former mentioned courses are revelant only to a small degree (and small set of applications) in the US IT industry where developing Just Another Accounting Application is the requirement of the hour. But as i just mentioned, these course need to be taught if you want to develop really good developers.
One categorization of professors i made was in terms of how they embrace emerging technology. On one end of the scale we have old (graduated probably a decade or more ago) hard nosed professors who teach the traditional courses. They are almost always Unix based courses taught in C/C++, Pascal etc. They refuse to learn Windows API, .Net, J2EE etc and i dont blame them. If you are thinking their jobs are in danger since lesser and lesser development is done using languages such as C/C++, you are only partially correct, since the importance of these courses are paramount in the development of a software developer. On the other end are the young (recent graduated) professors who eat, sleep and breathe modern OOP languages such as java, C#. Their courses are more often Windows based (VC++, VB, .Net) or they take the easy way out and use the platform independence of java. Students flock to the courses since after completion, they are equipped to put a few extra buzzwords on their resume which will be grep'ed by recruiters and hence land them cushy jobs in the industry. Point i am trying to make is that there is a wide ridge opening up within the teaching academia and being on either side is not always a bad thing.
Joel says - "But what about the CS mission of CS departments? They're not vocational schools! It shouldn't be their job to train people to work in industry. That's for community colleges and government retraining programs for displaced workers, they will tell you. They're supposed to be giving students the fundamental tools to live their lives, not preparing them for their first weeks on the job.". True but who cares, what matters to CS teachers is the pay check at the end of the semester and them keeping their jobs. Teaching is definetly a lucrative profession. Care for a PhD anyone ??
And here are the points i have a difference of opinion on.
There's nothing hard enough about Java to really weed out the programmers
My argument isn't against the merits or demerits of using java to weed out the good programmers from the mediocore, but rather with the approach of using a programming language in itself to find out who the best programmers are. The best in the IT business rarely are concerned about the programming language skills of a new hire (especially a recent graduate). For instance companies such as Microsoft, Amazon.com, Google, Yahoo have a series of interview stages, almost all of which test you logical skills. Only the initial first interview touches upon techinical details and this is mainly to weed out those that escaped the resume-grep screening held prior. For instance i had the pleasure of interviewing with Amazon.com and apart from the initial 5 minutes of the first screening interview, i wasn't asked anything very technical. The following series of interviews (all telephonic) were all about testing my mental aptitude and ability to solve logical problems. When trying to solve problems of the scale faced by Amazon, efficiency and robustness count and my java-schooled brain failed to make the cut. For those really interested in using java as a weed-out mechanism, i'm sure there are several way to do so as well, for instance asking how a memory leak may be caused in java or how memory alignment of arrays happen in java. The real good programmers will be able to provide the right answers.
Here pops up and interesting point, as highlighted by Joel - "Now, I freely admit that programming with pointers is not needed in 90% of the code written today, and in fact, it's downright dangerous in production code. OK. That's fine. And functional programming is just not used much in practice. Agreed."
If you were for instance working for the IT department of a company which is primarily in the finance sector or health care sector, the chances of you working in a language other than Java or .Net are remote. This fact is well understood by CS students and hence their approach towards learning computer science fundamentals is half hearted as best. They are more interested in learning the latest and newest technology buzzword since that's what the industry demands and that's what is going to fill the coffers at the end of the month.
Having interacted with a variety of developers during the past year, i have developed the following opinion.
Students are happy with what they get from the curriculum offered by java schools
The general approach for a CS student targetting a cushy job working in the IT department of non-IT related sector (such as finance, healthcare etc) is ... teach me something (whatever latest technology buzzword doing the rounds) that will get me a job and i will deal with the rest. I want to learn how to design business applications, how to identify business requirements, how to create functional specifications which i will ship to the code-monkey sitting halfway across the world. Let him concern himself with the techincal grunt of implementing him, that ain't my job. My job is to deal with the client and charge a bundle for that while i get the offshore programmer geek (code-monkey) to team up with another half dozen wannabe-programmers-turned-QA-guys to implement the damn thing while i pay them what is essentially peanuts to me. Let him use whatever technology he wants, i dont care, my marketing guy will gift wrap it and sell it to the client. Just make sure we put enough QA guys in there to ensure the bugs are more obscure and harder to find. As more and more software development is done using languages which use Managed Code (.Net), java etc .. the requirements for developers to know the hardcore basics of computer science such as assembly grow thinner by the day. It is undisputable that productivity of a developer is more when programming using Managed Code as opposed to unmanaged ways of C/C++. In this day and age productivity is crucial as is time. Who cares about effeciency, lets just throw some more cheap and powerful hardware at it and let the client pay for it. Who cares if boxing/unboxing of primitives in .Net is an expensive operation, the fact that it is implicit makes for better code and readability and hence easier maintainence of software and that counts more in a service company. We are not out there to write the next google beater, just give us the next accounting application and content management system to droll over.
You typically find such students taking software design courses (courses where they learn how to identify business objects in an application, learn how to write funky looking functionalal specifications etc). In essence they are looking for mainly design courses. They supplement it with minors in business realted subjects (which is where they will ply their trade ultimately). They would be least bothered about Hash Tables using pointers, sementation, paging, compiler optimization. A course in Enterprise java, .Net coupled with an OOP programming course is all they essentially view as requirements to become a competent software developer. With such a mindset it is hard to convince them of the merits of the computer science fundamental courses. More so java schools fit in perfectly with what these students are looking for.
Too bad you guys had to use punched cards to do your coding, guess what my code monkey living half way across the globe uses swipe cards to get to his terminal everyday so that he can do my coding. Neat ain't it. So much for perils of java schools.
Posted by Nikhil on Wednesday, 4th January 2006 in TechnoBabble