Teaching Java, teaching what?

[Arne Vajhøj]

I don't see it myself, that teaching servlets would be more
time-consuming than teaching Swing (or JavaFX for that matter). In fact,
I think that teaching servlets affords an excellent opportunity to
introduce students to important real-world stuff:

1) using libraries;

2) the ubiquity and importance of app servers;

3) HTTP request-response handling;

4) how servlets underlie many Java frameworks, with a brief intro to how
the frameworks build upon the servlet API.

Can this be done in 30 hours, especially for programming neophytes?
Maybe not.

Almost certainly now.

It is very useful topics - more useful than Swing, but I can not
see them as step one.

There are too much stuff to learn to get anywhere.

I provide some help at a danish web forum for IT problems. And
there are one university where they have a programming course
in first semester. They decided on Java - which I think is a
fine choice. But they want them to learn Java by doing JSF web apps,
RESTful web services etc.. The result is not pretty. The students
that should learn about data structures, control structures, OOP
etc. are looking at things generated by Eclipse wizards and they have
no idea about what all that stuff is doing.

But I'm not convinced you can accomplish more by doing "first
steps with Swing". The issue here may be that 30 hours isn't
enough...

If kept simple with JLabel, JTextField, JButton etc. I think they
can make something work *and* understand what they are doing.

but I myself have a gut feeling that you'd do better with a
servlet approach.

I am not sold on that.

For a barebones first approach, I think we can over-emphasize the
importance of GUIs (web or desktop) as being what beginners expect to
see, or what they feel comfortable with. I'm probably dating myself
here, but back in the '70's when I learned programming with FORTRAN 66
and FORTRAN 77, I (and most of my peers) grokked program output to
printer or tape, and program input from similar sources. It's also not
difficult to relate a console input prompt to an HTML text input box -
students understand that what matters is what you do with the input, not
so much how you got it.

Let me put something else out there. 30 hours is a short semester if we
suppose three 1-hour classes per week. Is it even realistic to try and
introduce any kind of GUI (Swing, JavaFX, servlets with simple HTML etc)
in 30 hours? Perhaps console output is all you should shoot for.

Console apps would certainly be better in the sense that there are even
less context to learn.

The problem here is probably more in the area of motivation. A console
app does not look fancy and that could be demotivating.

Arne

 

[markspace]

But they want them to learn Java by doing JSF web apps,
RESTful web services etc.. The result is not pretty. The students
that should learn about data structures, control structures, OOP
etc. are looking at things generated by Eclipse wizards and they have
no idea about what all that stuff is doing.

This is intuitively what I would have guessed. Beginning students need
to actually write their own code. It's part of the process that makes
them learn.

The problem here is probably more in the area of motivation. A console
app does not look fancy and that could be demotivating.

I think simple GUI calls would be OK. JOptionPane.showMessageDialog()
is fairly painless way of making GUI windows. Ditto for most of the
other JOptionPane static methods. You could get quite a bit of mileage
out of just that class.

If you wanted more, I'd keep the GUI layout very simple, and just give
the class the GUI code to copy. Show them where the entry point is and
just let them call that. I did a large project in my senior year of
school where two grad students had written most of the code and we were
just to "fill in the blanks" where the instructor removed the bits he
wanted us to learn. It was a fairly efficient way of understanding code
as well as having a large project working without a lot of busywork or
endless debugging.

Note that all Swing code is now not thread safe. It all has to be
called on the EDT. That's a further complication, but one I think
students should be exposed to. If not, you'll cause dissonance when you
tell them the way they've learned to write code all along isn't correct.
Some just won't believe you.

 

[Silvio]

On 12/9/2013 10:17 AM, Silvio wrote:

A desktop app is very standalone.

Yes, it is.

Web means:
- two apps: browser and server
Yep.

- knowledge of at least HTML required (CSS and JS optional)

Like I already mentioned.

- a little bit of knowledge about HTTP and the interaction
Likewise.


And web is often less OO than desktop apps, which may move
focus from the purpose of the course.

I usually get nervous twitches when people start saying something is
more or less OO. There is no such thing as general OO-ness and saying
that web is less OO than desktop is complete nonsense.

An entry level course usually focuses on general stuff like classes,
instances, encapsulation and methods. I personally think command line
test code is best suited there since it distracts the least from the
main topics.

Swing brings an enormous amount of extra logic into the picture. Apart
from the fact that you have to discuss components and hierarchies,
graphics, layout managers, event handling etc. it has a dirty API that
brings along a zillion names, adapters, patterns etc. Enough material to
warrant a course on its own (if you still think it is worth the trouble).

Given that the OP did not want to use a console UI I suggested an
alternative that enables beginners to do more with less upfront
knowledge than Swing or any of its siblings. And yes, you would need a
browser. Since nobody is acquainted to those it was probably a bad idea.

 

[Silvio]

On 10/12/13 10:56, Silvio wrote:

Way back when, I worked for a training company. My job was to develop
their Java training offering. One of my courses focused on the early
J2EE offering with particular focus on EJB. I used an early release of
Weblogic and built a CD containing everything required to run the labs.

I developed a collection of DOS batch files and Unix shell scripts that
automated the installation and configuration of the app server and it's
dependencies. The student would insert the disk, click the relevant
script file and in less than 2 minutes everything was up and running.

Make no mistake, this was heavy on the OO aspect of software engineering
with plenty of opportunity to delve into the darker corners of the
language. It worked a treat and I used and developed it over a period of
two years. I still have the CD somewhere... wonder if it still works?

I used to teach assembly (PDP-11 and IBM S/370), C and C++ in about the
same way, except that I had to use floppy disks. Worked great except
that floppy disks where extremely unreliable.

 

[Silvio]

Heh heh, my first Slackware came on 23 floppy disks downloaded over the
university network and installed on an old 386 with a monochrome monitor
... jeez, floppy disks, how long ago does that seem now?

Especially considering that my current Internet download speed is around
50 of those per second...

When I started my company almost 20 years ago I used to have my wife
bring floppy disks with software updates to my first clients. I once
sent her out with three copies and she had to make the trip twice
because all three failed.

 

[Arved Sandstrom]

Almost certainly now.

It is very useful topics - more useful than Swing, but I can not
see them as step one.

There are too much stuff to learn to get anywhere.

I provide some help at a danish web forum for IT problems. And
there are one university where they have a programming course
in first semester. They decided on Java - which I think is a
fine choice. But they want them to learn Java by doing JSF web apps,
RESTful web services etc.. The result is not pretty. The students
that should learn about data structures, control structures, OOP
etc. are looking at things generated by Eclipse wizards and they have
no idea about what all that stuff is doing.

I'd agree without qualification that introducing JSF or REST in a first
programming course, that uses Java, is too ambitious.

If kept simple with JLabel, JTextField, JButton etc. I think they
can make something work *and* understand what they are doing.

I'm not being combative here, but in the big scheme of things, that
knowledge will help the students how exactly? Apart from the top
students, who will probably get on with any approach to OOP, everyone
else - at best - will understand how to write simple Swing apps: some
will eventually (after further study) grasp the larger principles, but
many will not.

I am not sold on that.

For what it's worth, I'm not sold on it either. To phrase things
differently, *if* you had enough time to do a decent intro to core Java
+ enough time to introduce either Swing or servlets, I'd prefer
servlets. I just don't think 30 hours is enough to do either.

Console apps would certainly be better in the sense that there are even
less context to learn.

The problem here is probably more in the area of motivation. A console
app does not look fancy and that could be demotivating.

Arne

I think this is where the teacher needs to step up and be on their game.
If I were teaching a genuine intro class where practically everyone was
a novice [1], and let's assume it was 30 hours over a semester, and the
working language was Java, I think I'd spend the first 2 or 3 hours
providing context, without diving into code. Pseudocode maybe, on a
chalkboard or whiteboard, but no actual code for the first few sessions.

Part of what you'd cover is a basic discussion of I/O - how do you talk
to a program. Properly done, I think most students would get that I/O
to/from a console, or to/from a file, is just as much first class as I/O
through a GUI. And I think many would then understand that the true
program lies behind the interface.

AHS

1. Keeping in mind what markspace said, that the further away any of us
are from our own first introduction to programming, the less equipped we
probably are to remember what caused us problems.

 

[Stefan Ram]

I think most students would get that I/O
to/from a console, or to/from a file, is just as much first class as I/O
through a GUI.

I am teaching using a Windows console in Germany.

java.lang.System.out.println( "müßig" )

will print something like

mn¯ig

with the default settings in place, while

new javax.swing.JTextField( "müßig" )

will show the correct word.

Moreover, today, applications often read user input via a GUI
but only very rarely from a console. (I do not deem command-line
arguments to be reading from a console here).

After many modifications to my syllabus, I now /can/ arrive
at the first Swing programs within 30 hours. I posted the OP
here just to get to know whether this still makes sense.

 

[Jeff Higgins]

After many modifications to my syllabus, I now /can/ arrive
at the first Swing programs within 30 hours. I posted the OP
here just to get to know whether this still makes sense.

Yes.

Google translate gives me:

müßig-adjective
idle
pointless
futile
otiose
of leisure

müßig-adverb
idly

 

[Arved Sandstrom]

I am teaching using a Windows console in Germany.

java.lang.System.out.println( "müßig" )

will print something like

mn¯ig

with the default settings in place, while

new javax.swing.JTextField( "müßig" )

will show the correct word.

Moreover, today, applications often read user input via a GUI
but only very rarely from a console. (I do not deem command-line
arguments to be reading from a console here).

I agree that console input for general app users is now uncommon. I also
agree that CLI args (CLI invocation for that matter) is not reading from
a console.

I'd say this though, are you trying to teach users of applications, or
writers of applications? If someone who intends to be a software
developer can't get console input, they are toast. For that matter, I've
worked with corporate and government _user_ teams in just the last few
years that were still quite comfortable with green-screen type console
input apps, and with quite a few user teams that loathed - and were
adversely impacted by - badly designed GUIs (whether smartphone, desktop
or web app).

So I wouldn't focus too much on the methodology of input.

After many modifications to my syllabus, I now /can/ arrive
at the first Swing programs within 30 hours. I posted the OP
here just to get to know whether this still makes sense.

Let me ask this, Stefan. You "arrive" at the first Swing programs within
30 hours. Leaving aside the 5-10 percent of natural programmers, and the
bottom 25 percent that maybe shouldn't have been there, are you content
that the middle group is benefiting from a cursory exposure to Swing?

AHS

 

[Robert Klemme]

On 12/08/2013 01:30 PM, Leif Roar Moldskred wrote:

I'll add this: we're talking about teaching _programmers_, not users of
an application. Hence the comments about wanting to present a GUI rather
than a text console are not really relevant. A working software
developer is going to be looking at text console output and log files a
lot, and maybe debugger displays...regardless of what the user interface
is. So that's what you accustom your students to.

But then again there is the motivational effect: seeing something
visually in a graphical UI can be much more rewarding than some
characters on a console - at least for some. On that grounds I would
not totally dismiss teaching Swing - even if event based programming or
user interfaces is not the primary goal of the lesson. Some care should
be applied to not focus too much on the Swing side then, e.g. by
providing some framework or application where learners fill in certain
parts.

Kind regards

robert

 

[Arved Sandstrom]

But then again there is the motivational effect: seeing something
visually in a graphical UI can be much more rewarding than some
characters on a console - at least for some. On that grounds I would
not totally dismiss teaching Swing - even if event based programming or
user interfaces is not the primary goal of the lesson. Some care should
be applied to not focus too much on the Swing side then, e.g. by
providing some framework or application where learners fill in certain
parts.

Kind regards

robert

Robert, others have made that point too, that seeing something visual (a
GUI) is motivational...as you say, at least for some. I truly don't know
how important that is, since I've not been a novice for decades. It does
occur to me that there are plenty of programming languages where you
would not even remotely contemplate introducing GUIs in a first semester
course, and students still manage. Java makes it just easy enough to
introduce a GUI through Swing (AWT before that, for that matter); I tend
to agree with you that little emphasis should be placed on the Swing
code itself.

AHS

 

[Stefan Ram]

earlier: /why/ are these students taking your course ? Is it as a first step

I am teaching at an adult evening school, where everyone can
attend who pays the fee for the class. The courses are
titled »Java - Grundkurs« (»Java - Fundamentals«, usually 18
hours, no Swing, but algebraic, imperative, procedural and
structured programming) and »Java - Aufbaukurs« (»Java -
Advanced Course«, sometimes only 12 hours, OOP + Swing).
(The contents of these two courses was determined by me.)

Why students attend, I can only guess! The save guess would
be: »to learn Java«. They range from college students of
computer science, via professional programmers (but in other
languages) to hobbyists.

where most of them expect that they'll take further courses later (or drop out
completely and never think about programming again) ?

Some drop out, some might have hoped to learn programming
during the course, but might be somewhat disappointed when
they learn that not the whole world of Java and computer
programming can be explained in 18+12 hours.

~~

I now have streamlined my advanced class to arrive at Swing
as early as possible, this means I have dropped everything
that is not needed for the first meaningful Swing program,
such as implementation inheritance (which is sooo AWT!), but
I do treat interfaces extensively before starting Swing.

Actually, I like this, because it gives students a reason to
learn about interfaces and spares them from artificial
examples, such as

class cow extends animal
{ java.lang.String mySound(){ return "moo"; }}

and instead gives them real-world examples, such as

public void actionPerformed( final java.awt.event.ActionEvent event )
{ Main.this.text.setText( Main.this.text.getText().toUpperCase() ); }

(Yes, I /have/ told my students that »Main.this.« usually
can be omitted!)

So it's alright with me to teach Swing from the technical
point of view, I just wanted to know whether it still makes
sense from the strategic/political point of view.

While some have posted that they would like to spare the
students from the technical details of Swing programming by
giving them templates of source code, this is actually the
part that I like the best, because the intricates of Swing
can be used as a reason why one has to learn the implementation
of interfaces, the lifetime of fields and so on.

 

[Stefan Ram]

part that I like the best, because the intricates of Swing

s/intricates/intricacies/

 

[markspace]

Why students attend, I can only guess! The save guess would
be: »to learn Java«. They range from college students of
computer science, via professional programmers (but in other
languages) to hobbyists.

I think is is too broad of a range. I think you should decide whether
you want to cater to hobbyists or professionals. (You could even split
your class into two, one for each.) The professional class should
assume a knowledge of algorithms and programming methodology. The
hobbyist course should assume neither. Trying to split the middle
ground isn't going to serve either group.

Actually, I like this, because it gives students a reason to
learn about interfaces and spares them from artificial
examples, such as

I think this is fine, as long as you are leading up to it. I offered
the idea of templates because I was concerned that you might be trying
to fit in Swing before it was really needed or useful. As an example of
inheritance, interfaces and aggregation, it's great, as long as the
students are ready for it.

I'm still concerned that you're introducing multi-threading too early,
but I'll let you address that as well.

 

[Eric Sosman]

Why students attend, I can only guess! The save guess would
be: »to learn Java«. They range from college students of
computer science, via professional programmers (but in other
languages) to hobbyists.

Elsethread you wrote

[...] I now often have only
30 hours to take students from »no programming experience
whatsoever« to »first steps with Swing« [...]

But now you're saying "no programming experience whatsoever" is
really not correct for some of your students, maybe not even
for any of them. Perhaps you need to develop a more detailed
picture of the audience for which your class is intended, and
then adjust the syllabus accordingly.

Here in the States there's a popular radio program about
matters automotive: maintenance, buying advice, strange problems,
and so on. One of the program's pearls of wisdom is that you
should not take your car to a garage that advertises "We Specialize
In All Makes And Models!" Maybe your hope of doing "We Cater To
Every Level Of Experience And Interest!" has a similar problem ...

 

[Stefan Ram]

Oh, in that case I think the answer is a fairly straight-forward
"No, not really." 'Knowledge of Swing' can be useful to have,
particularly for hobbyists, but it's not going to matter much
on someone's CV.

Recently I heard people talking about IntelliJ Idea (which
is replacing Eclipse in Android development) and Burp
(a web Proxy and test suite), both of which I believe to be
Swing desktop applications.

 

[Arne Vajhøj]

Robert, others have made that point too, that seeing something visual (a
GUI) is motivational...as you say, at least for some. I truly don't know
how important that is, since I've not been a novice for decades. It does
occur to me that there are plenty of programming languages where you
would not even remotely contemplate introducing GUIs in a first semester
course, and students still manage. Java makes it just easy enough to
introduce a GUI through Swing (AWT before that, for that matter); I tend
to agree with you that little emphasis should be placed on the Swing
code itself.

Languages with easy GUI are widely used in basic programming courses:
Java, C#, PHP.

The most notably difficult GUI languages are C/C++ and I believe those
are becoming rare in basic programming courses these days.

Arne

 

[Arne Vajhøj]

I think is is too broad of a range. I think you should decide whether
you want to cater to hobbyists or professionals. (You could even split
your class into two, one for each.)

He may not have a choice.

It sounds like "public service" courses funded not only
by participants but also by city/region/state/country.

And the possibilities for changing content and splitting
participants may be very limited.

Arne

 

[Arne Vajhøj]

Recently I heard people talking about IntelliJ Idea (which
is replacing Eclipse in Android development) and Burp
(a web Proxy and test suite), both of which I believe to be
Swing desktop applications.

Yes.

And there are several other. Like various DB2 admin tools.

But it is still highly exceptional.

Arne

 

[Arne Vajhøj]

I'm not being combative here, but in the big scheme of things, that
knowledge will help the students how exactly?

Writing some code and being able to see it work without it appearing
to be black magic is learning to program.

Apart from the top
students, who will probably get on with any approach to OOP, everyone
else - at best - will understand how to write simple Swing apps: some
will eventually (after further study) grasp the larger principles, but
many will not.

You want to show something that is OO.

You need input and output preferably something that looks
pre-1990.

Swing delivers both.

For what it's worth, I'm not sold on it either. To phrase things
differently, *if* you had enough time to do a decent intro to core Java
+ enough time to introduce either Swing or servlets, I'd prefer
servlets. I just don't think 30 hours is enough to do either.

Servlets would be more useful job wise.

But you would need more time to teach servlets than to teach Swing.

Server, HTML and other useful topics that in this context just
distracts from the topic.

Console apps would certainly be better in the sense that there are even
less context to learn.

The problem here is probably more in the area of motivation. A console
app does not look fancy and that could be demotivating.

Arne

I think this is where the teacher needs to step up and be on their game.
If I were teaching a genuine intro class where practically everyone was
a novice [1], and let's assume it was 30 hours over a semester, and the
working language was Java, I think I'd spend the first 2 or 3 hours
providing context, without diving into code. Pseudocode maybe, on a
chalkboard or whiteboard, but no actual code for the first few sessions.

Part of what you'd cover is a basic discussion of I/O - how do you talk
to a program. Properly done, I think most students would get that I/O
to/from a console, or to/from a file, is just as much first class as I/O
through a GUI. And I think many would then understand that the true
program lies behind the interface.

You and I may find a console intuitive.

But that is not what is common today.

As an example look at the signing thread. The OP had found a nice
guy telling what command to use. But the explanation could just as
well had been written in Chinese - the OP was not thinking that way
at all. And he is not alone. It may be unfortunately that the socalled
digital generation in many ways know less about computers than the
previous generation, but that is how it is.

Arne