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]
You know your preeching to the chour here. personally after my month at SU so far I almost wish they taught me C++ instead. But then again, you’ve been reading up on my adventures, you know why.
I’m now in the introductory Java class and have seen BlueJ once when my instructor demonstrated it in the class. Later we are using DrJava and JCreator to code our programs.
I agree that while BlueJ is easy for students to understand OOP concept, it has its side effects by hiding much information from them.
My freshman year was the last year MSU taught in JGrasp. Useless knowledge.
I think that a big problem in CS courses at MSU right now is that they concentrate at teaching students how to use an IDE instead of teaching the language itself.
Rather than something like jgrasp, eclipse if they want to makes lives easier (syntax completion) or pico if you want to go under the hood.
I would make them code in friken notepad for the first 2-3 months just to drive home the message that all you need to program is a compiler and a text editor of sorts.
I learned java with notepad and pico, and I have to say that it makes it a whole lot easier to use the language…since you’re not always going to have jgrasp and bluej. I dare any MSU professor in a basic java course to assign their students a notepad-use-only program. They best have a few boxes of Kleenex and some Xanax on hand.
It can be done. In fact it was done this way when I was a freshman there. We wrote most of the introductory programs using pico on pegasus.
same here. mix in a splash of bluejay that i had to teach to myself. and you get my cmpt183
ahh. i meant jgrasp
I could not disagree more. With BlueJ, the student automatically understands important issues such as modularity and state, intutively. Objects in BlueJ are “live”. It almost feels like a Smalltalk environment.
Do they really though? Because I really don’t see the marvelous results of the BlueJ approach. What I see is a throng of students who lack the basic programming skills, in addition to the very shaky grasp of the OO concepts.
Most of my generation started using really old school stuff. My first programming steps were done in C and Basic. I compiled my first Java program by logging into a unix workstation via ssh, and using vi and javac. I turned out just fine – and most of my colleagues did to.
The only way to actually introduce students to real programing – the kind they will be required to do at at their future jobs is to wean them off BlueJ. So why not just start them off right. They might struggle a bit at the beginning but that’s normal. We all went through it. Ultimately, they either get it or not.
But I think what we are doing here, is creating yet another hurdle they have to jump through. Now they will have to make the leap from BlueJ Java to real Java at some point, and it might be difficult.
So instead of a uniformly steep difficulty curve, we fist give them a very gentle hill, then a 50 feet brick wall to climb, just so that they can catch up to the rest of Java students who were climbing the steep curve since the begging. Most of the BlueJ kids will never catch up because they lack the strong programing foundation you get from doing things the old school way.
BlueJ is really helpful for students to grasp the concepts of OO programming. It is entirely true it won’t teach them how to get their hands dirty on using a text editor and a compiler, and they may even not be able to create a program from scratch without BlueJ.
That’s because it’s not the purpose of BlueJ.
They will have to learn how to use these tools anyway if they want to do real programming, but they certainly don’t have to learn OO concetps the right way that’s why it is important to teach them, and the earlier, the better.
That’s the purpose of BlueJ.
I am one of current developers of BlueJ.
There’s some serious misrepresentations going on here. Firstly, as Fab pointed out, BlueJ is not designed to teach how to install JDKs, or write/compile Java programs from the command line. Those things need to be learnt separately – but BlueJ does not prevent those things from being taught. If students are lacking basic knowledge about CLI environments and classpaths after completing a course, it has nothing to do with BlueJ – it’s just that the course didn’t adequately cover those topics. The title of your post, “BlueJ considered harmful”, and the general tone, imply that you’re blaming the tool itself.
You allude to students who “think that ‘programming’ involves clicking on things in a graphical IDE”. Well: generally, it does. I use Eclipse and Netbeans and both of them have graphical UIs in which you click on things. They also require me to type Java code, as does BlueJ. Sure I can wrote code in a text editor that doesn’t have any mouse support, but to suggest that is an important skill is ludicrous.
You refer to “IDE specific hooks that will not compile on the instructor’s machine”. What on earth are you talking about? BlueJ compiles plain old Java. There aren’t any “IDE specific hooks”. If a project compiles in BlueJ, it will compile from the command line just as well.
You talk about a “thinned down BlueJ brand of Java”. Well, BlueJ allows the full Java language and API to be used. Nothing is “thinned down”. No part of the Java code produced by students using BlueJ is BlueJ specific. BlueJ is written in Java, it runs on the Java VM, and it allows to write code using Java. Your statement is FUD.
At times, you seem to be half on the right track. I’ll agree that there are important concepts students should learn which BlueJ allows you to temporarily sidestep (which is course the whole point of the tool). Most of the points you list as being important for students to know after an introductory Java class are well and good (I wouldn’t go so far as “calling native code from within Java” for instance, but that’s not what I’m interested in debating right now). However, you are blaming BlueJ while this is really a problem with course structure.
Actual programming – the writing of code to perform a task – and dealing with classpaths etc, are actually two different activities. They can be dealt with separately. BlueJ allows learning the former without having to previously learn the latter. Nowhere does BlueJ say that you should not learn the latter at all.
BlueJ is a tool. Objects First is a teaching approach. Neither are responsible for the problems you’re seeing with your students.
@ Davin: Well, maybe I came down on BueJ a little too strong. My problem is not with the tool itself – I do see it’s value as a teaching tool that will help students grasp OO paradigm more easily. It does have a valid purpose.
What I did object too is using BlueJ exclusively and structuring the whole two semester Java course around it. As I mentioned before, I have been approached by CS students who were just starting the higher level CS classes and were completely at a loss because they didn’t actually know how to program outside of BlueJ.
The “IDE specific hooks” phrase is a bit unfortunate. What I meant was that BlueJ came with some “helper” classes that students could use. For example, I remember that there was a custom “keyboard input” class somewhere in there that would allow students to grab user input by popping up a modal dialog box. A lot of students heavily relied on that class – and if I remember correctly their code would just throw an exception when run outside of BlueJ environment because the class was missing. This might have changed since then – I haven’t worked with BlueJ for years now.
So again – I have no problem with BlueJ itself. I have a problem with the way people used it in class. So perhaps I should change the title of my post to “Using BlueJ as the only teaching tool and ignoring practical stuff considered harmful” or something like that. :)
disclaimer first:- I don’t use BlueJ and whenever I code in java I use Netbeans. I have played with blueJ for evaluation purposes only. Java is only one of the languages I use at work.
There is a place for BlueJ in the classroom. BlueJ helps learning OO concepts. To think in OO is the most difficult part, and any tool that can help in this direction is useful.
as for wrting code in a pure text editor and using command line to compile it is so not necessary anymore. It was probably the only way, in your olden days, it’s not in today’s world. It’s like teaching any new driver how to use a crank to start your car in today’s world. or to eat chicken, you have to know how to raise them first, just because our grandparents had to raise their own chicken before they can eat them.
all big organisations (believe me I have worked in organisations with over 50,000 employees worldwide) I have worked in for the past 19 years use one of the commercial IDEs today where they don’t do things at command line. Why ? One word . productivity !!!
can I use command line to set classpath or to compile ? you bet I can. and If I can, any computer science student can , as long as you provide them the instructions the first time. Let’s face it when java came out , you too had to rely on Sun’s instructions to do the compilations, so what’s the big deal.
if they don’t know command line, it’s not the fault of BlueJ, there is a gap in the computer scence course curriculum itself, they should also be taught scripting at the OS level , whether in Linux, Unix, or Windows? or how to run command at the shell levels.
anyway that’s my 2 cents.
@ Davin:
I can tell you that when I first learned Java at university a decade a go, we used the hard (TM) way. But me and my lab partner found BlueJ by ourselves and made good use of it. Now, 10 years later having worked professionaly in lots of languages, played with squeak and whatnot, I had a renewd look at Java. I immediately downloaded BlueJ and was pleasantly surprised to find that it hadn’t changed much and still worked great. Sure it is nothing like squeak but it is a very compelling environment that actually goes nicely together with actuall editing of the source code in for instance emacs.
I don’t understand this fanatical idea that OOP is a difficult concept, so much so that something like BlueJ should even be considered. I remember the first time we broke away from imperative programming to the OO method… and it all made sense. Polymorphism, inheritance, and overloading seemed rather straight forward and to the point; at least more so than when I first learned about pointers and passing arguments by reference. I am talking about when I learned to program in C++ but now I am taking a Java course and it is all kinds of jacked up. I feel that if this instructer approached our learning ciriculum like my C++ professor did we would be learning a whole lot more about the language.
I understand the OOP concept and I’m sure the rest of the students (some of which are new to programming) understand it to. I think BlueJ is a complete waste of my time and it is frankly insulting learning from a book that revolves around the IDE.
Anyway… I hate BlueJ. Point and click is no way to teach a language.
I’m not blaming the tool.
I am currently taking a Java course after learning Python.
The course requires BlueJ.
I’m used to writing my code completely…not leaving out parts that will actually allow it to run in the terminal. I’ve had such a had time teChing myself because the instructors are using–in my opinion– the tool but not teaching the language.
I’m so frustrated that I’m seriously considering switching courses.
I can see, perhaps, how BlueJ could be really helpful to a complete newbe…but if you know on any level what should be going on…it’s just really frustrating…
@ Davin: