At Montclair State University introductory Java classes are taught using the BlueJ IDE. I cannot say that I do not understand the reasoning behind this choice. I know exactly what the instructors and administration is trying to achieve here. You see, when you teach students their first modern programming language the most difficult obstacle awaiting them is making the leap from imperative programming mode to object oriented programming. It is an extremely difficult transition and some people may never be able to make it.
In fact, finally getting object oriented paradigm is possibly the most profound moment in a young programmers career. It is a defining conceptual leap and prepares him for many similar leaps he will have to make in the future as a programmer. Figuring out how to make this leap, is an extremely crucial process.
The idea behind the Objects First approach is to completely bypass that leap. You teach them object oriented principles first, and equip them with tools that completely hide the imperative layer. In BlueJ students write a class, and then initialize it by right clicking on it’s icon and choosing constrictor from a context menu. They run methods by clicking on an object box and picking a method name from a similar menu. You do not show them the main method till very late in semester.
The theory is that the leap from OO to imperative paradigm is much easier to make then from imperative to OO. This may be true. But there is a serious drawback to this methodology.
It keeps students chained to a single, very limited IDE – namely BlueJ. They are not able to write or execute Java code without assistance from this specialized tool until the instructor teaches them about the main method. From experience I know that this time usually comes in the last 2 weeks of the course, when the pace is really frantic and everyone is busy preparing for finals, and finishing up projects.
Objects First students now have to make another big leap. They need to abandon the comfy GUI based BlueJ interface and learn how to run and compile Java in the real world. Up until now the IDE did everything for them, but now they suddenly need to learn allot of new things – like setting up your system path, navigating in a CLI environment and etc…
All of that stuff is easy, but it can be incredibly scary to a student who was previously taught that “programming” involves clicking on things in a graphical IDE. They are simply not prepared to deal with this type of technical problems.
Today I helped a group of students who were completely mystified by the mysterious black box of cmd.exe. I swear I have never seen anyone so completely stumped by a command prompt. I think this is unacceptable and shameful for MSU as a teaching institution. We should be training young hackers, and encourage them to get down and dirty and messing around with the guts of their OS and programming environment. Instead, we are churning out batches of GUI clickers.
I think that BlueJ shelters students from some aspects of Java until it is to late in semester for them to develop good habits and instincts about them. In my personal opinion a student after introductory Java class should be able to do the following:
- install the java runtime and sdk himself
- set up the programming environment (path, classpath)
- run and compile programs on the command line
- create jar files on the command line (including writing of a manifest)
- be able to write short build scripts that would compile, and jar their code into a single binary file ready for deployment (they don’t have to know ant – simple batch files are ok)
- have some grasp of using source code repository
- using incorporate precompiled Java libraries and jar files into their program
- calling native code from within Java and capturing output
All of these are crucial basic skills that will be expected from any programmer applying for an entry level Java programming position. It is probably a good idea to teach these things as early as possible so that they become like a second nature to them. Unfortunately, our introductory java classes currently do not teach any of these skills. Instead they concentrate on a funky visual IDE. More advanced Java classes assume the skills above are already known by the students.
What is the end result? Most students submit bundles of unstructured java files with hard-coded paths, and IDE specific hooks that will not compile on instructor’s machine. They do not know how to deal with classpath problems. They do not know how to test their work properly. They have no clue how to use jar files and are completely stumped when forced to use say JDBC library. I even knew students who would spend most of their life in the computer lab because even after 4 years in a Java centric CS program they still could not figure out how to get Java working on their home machines.
What we do right now is teach them how to use a specific IDE to write Java like code. We are not really not teaching them the language itself – rather a thinned down BlueJ brand of Java.
It’s kindoff like teaching students painting by showing them specific brush techniques for a synthetic fiber brush of a specific brand and size. Sure, it will improve their technique, but it will not teach them about perspective, composition, color theory and multitude other things that are important for a painter to know.
IDE is a productivity tool. You don’t really need one in order to write code just like you don’t need Microsoft Word to write an essay. Students should be forced to write their first few programs in a basic text editor and compile them from the command line.
Then, we can allow them to use an IDE of their own choice. We can of course give them a list of the good ones to save them some trouble looking (ie. eclipse, netbeans etc..) but in the end we should not require them to learn a specific IDE.
While I think that Objects First methodology has it’s merits, I think it is currently doing more harm than good. The IDE centric approach is wrong. We are sheltering students from the quirks of real Java by forcing them to work around the weird quirks of BlueJ knowing full well that they will need to change the IDE to another soon. In effect, they are no longer adequately prepared for real-world programming tasks.
But that’s just my opinion. Your millage may vary.
[tags]java, programming, bluej, ide, command line[/tags]