Teaching Java, teaching what?

[Arne Vajhøj]

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).

Basic OS understanding, being able to navigate command line / shell,
install and troubleshoot server applications are necessary to become
good developers.

But that is not the same as making it part of or a prerequisite for
a basic programming course.

Basic course should focus on a specific topic and then later the
students can try and make a whole out of all the small fragments.

Arne

 

[Arne Vajhøj]

I usually get nervous twitches when people start saying something is
more or less OO. There is no such thing as general OO-ness

Unless you will claim that there is only two possible
states non-OO and OO, then something can be more or less
OO than something else.

and saying
that web is less OO than desktop is complete nonsense.

Calling something nonsense is not a very convincing argument.

Try instead of writing an application able to add two integers
and display the result in Swing, Struts 1.x and JSF - and count
number of occurrences of inheritance, polymorphism and encapsulation
for each compare dto number of lines written.

I think you will find that Swing has a lot of OO features, while
Struts 1.x and JSF are more multi-paradigm oriented, which means
less OO.

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,

But that is exactly what you would want to discuss in an OO course.

graphics,

Don't need that for a basic Swing app.

layout managers,

There will be a bit of black magic with that, but it is nothing compared
to CSS.

event handling etc.

That is very OOish.

it has a dirty API that
brings along a zillion names, adapters, patterns etc.

You can do basic Swing with a modest number of classes.

Arne

 

[Arne Vajhøj]

Spot on. *Web development* is actually a misnomer. I prefer 'web
interface'. The 'OO'ness of something shouldn't depend on the user
interface.

Not particular surprisingly the OOness of the user interface
depends on the user interface.

An OO system encapsulates the human concepts of 'business'
and 'system' and presents (or should present) an end user interface
agnostic facade to any client that might want to use it.

You can also use OO in many user interfaces. OO is not restricted
to business logic and similar.

In the classic [simplified] three tier web application we have a browser
who's responsibility is to interface with a human being, a 'bit in the
middle' who's responsibility it is to implement the business logic (for
want of a better term) and some mechanism to persist important data.

The application executing on the bit in the middle is the thing we are
interested in. Whether it is 'OO' or not has nothing to do with a
particular interface.

The middle tier is also responsible for user interface with
a traditional wen app (HTML generated dynamically server side).

With a modern static HTML/CSS/JS and services only server side model
not so.

But that model is still heavy OO in user interface.

Arne

 

[Joerg Meier]

There will be a bit of black magic with that, but it is nothing compared
to CSS.

Swing also allows for absolute positioning without layout managers, which
while not the best idea in production is a perfectly valid path for a
classroom after a few short words about how layout managers can alleviate
the need for absolute positionings and their other advantages.

Liebe Gruesse,
Joerg

 

[Silvio]

Unless you will claim that there is only two possible
states non-OO and OO, then something can be more or less
OO than something else.


Calling something nonsense is not a very convincing argument.

Try instead of writing an application able to add two integers
and display the result in Swing, Struts 1.x and JSF - and count
number of occurrences of inheritance, polymorphism and encapsulation
for each compare dto number of lines written.

I think you will find that Swing has a lot of OO features, while
Struts 1.x and JSF are more multi-paradigm oriented, which means
less OO.


But that is exactly what you would want to discuss in an OO course.


Don't need that for a basic Swing app.


There will be a bit of black magic with that, but it is nothing compared
to CSS.


That is very OOish.


You can do basic Swing with a modest number of classes.

Arne

Components and event handling have nothing to do with "OO". You can do
both in a procedural style. In fact, in the early days of event driven
user interfaces it was mostly done in C in a very procedural way.

OO is no more than a programming paradigm that has spawned a number of
object oriented programming languages. One can do analysis and design
with the intend to program the system in an object oriented way. I can
live with calling that object oriented analysis and design.

But that is about it. There is no such thing as an object oriented
database (as opposed to an object database) or an object oriented user
interface (as opposed to a component based one).

I have heard people argue that variable naming conventions can be more
or less OO or that having more than X arguments to a method is not OO.
The lost of things that can be or not be OO to some people appears to be
endless.

And I will continue to call that nonsense.

 

[Silvio]

For an introductory course in programming, I'm not so sure you do.
(Of course, if you use Java as the language you pretty much have
to, but then I'm not sold on Java as a good choice for teaching
programming.)

OO is all about "programming in the large." It's about how to
structure the code to make a large program manageable and
understandable.

Students in an introductory course, though, are still struggling
with "programming in the small" : what a variable is, how to
track program flow, loops and conditionals, what a method or
functional call is, call-by-reference vs. call-by-value,
arrays and data structures, the idea of libraries and using
them, what compilation is, I/O, how to debug and all that
other jazz that seasoned programmers barely even think about.

I think introducing OO concept at this stage (except possibly
as a final "this is where you go from here" at the very end)
would just be so much magical "because that's just how it is"
that'd only serve to distract and confuse the students from
those core concept they really need to focus on.

I completely agree. OOP should come into play when thing reach a volume
where OO makes sense. Otherwise it is just religion: this is how "we"
think it should be done so you must do the same, you will understand why
once you grow up.

I think using something akin to Scala scripting where you can write some
(procedural-like) code using variables that get wrapped into an object
during translation might be a better starting point.

 

[Stefan Ram]

What do you mean with "easy" and "difficult" here? I can't see how, say,
GTK or QT in C and C++ are any more difficult to use or teach than Swing.

Swing is part of the Java standard edition. The C++ standard
does not include a GUI toolkit at all. So, first problem:
One has to make a strategical decision which third-party
toolkit to use and check additional license terms.

Java automatically memory managemes all Swing objects. Using
C++, one has to manually memory manage all the GUI objects,
good luck!

 

[Arne Vajhøj]

What do you mean with "easy" and "difficult" here? I can't see how, say,
GTK or QT in C and C++ are any more difficult to use or teach than
Swing.

(As an aside, whatever happened to Tcl/Tk?)

Easy and difficult are somewhat subjective.

But I think think that most programmers will consider
Java Swing, Java JavaFX, C# win forms, C# WPF and PHP HTML
easier to get started with than C/C++ GTK, Qt, MFC and Win32 API.

The language is more difficult, the API's are more complex
(but also more powerful), it is more low level and it is more
coupled with the underlying platform.

Arne

 

[Arne Vajhøj]

For an introductory course in programming, I'm not so sure you do.
(Of course, if you use Java as the language you pretty much have
to, but then I'm not sold on Java as a good choice for teaching
programming.)

OO is all about "programming in the large." It's about how to
structure the code to make a large program manageable and
understandable.

Students in an introductory course, though, are still struggling
with "programming in the small" : what a variable is, how to
track program flow, loops and conditionals, what a method or
functional call is, call-by-reference vs. call-by-value,
arrays and data structures, the idea of libraries and using
them, what compilation is, I/O, how to debug and all that
other jazz that seasoned programmers barely even think about.

I think introducing OO concept at this stage (except possibly
as a final "this is where you go from here" at the very end)
would just be so much magical "because that's just how it is"
that'd only serve to distract and confuse the students from
those core concept they really need to focus on.

Actually I somewhat agree.

But the question we were discussing was 30 hours course in
Java and OOP.

So OOP was somewhat a given.

Arne

 

[Arved Sandstrom]

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

You'd have to rule out PHP - we've already decided that a web stack is
out. If you can't do servlets, you can't teach PHP on Apache, for
example. C# or VB with WinForms in VS is about as simple as it gets -
far outstripping any Java environment - but I'm not convinced (for the
same reasons as Swing and Java) that you learn the core language or
programming concepts any better by having a GUI.

FWIW Python and Perl, among others, still are good for very easily
creating GUIs. But the same arguments apply.

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

Arne

Might be a good argument for returning to C or C++ to teach [1]. That
way you don't bother wasting time with a GUI, and stick to teaching core
concepts.

AHS

[1] I'm being a bit of a pissant when I recommend C or C++. I think C is
useful, but I'd never suggest it as a first language. As for C++, I just
spent the past 6 months re-reading my Scott Meyers "Effective C++"
books, my Andrei Alexandrescu "Modern C++ Design" book, my Vandevoorde &
Josuttis "C++ Templates" book, and online sources covering C++11. I
can't think of a language that I am less likely to recommend to anyone
than C++...the potential for disaster and productivity stifling is enormous.

 

[Arved Sandstrom]

Unless you will claim that there is only two possible
states non-OO and OO, then something can be more or less
OO than something else.

[ SNIP ]

I'd like to think that there's a core definition of OO that we can agree
on: objects (not necessarily classes), encapsulation, dynamic dispatch,
and inheritance/subtype polymorphism (the latter 2 not always being
identical).

If you've not got the above, I don't see how you have OO. Conversely,
other features are extras.

AHS

 

[Arved Sandstrom]

Basic OS understanding, being able to navigate command line / shell,
install and troubleshoot server applications are necessary to become
good developers.

But that is not the same as making it part of or a prerequisite for
a basic programming course.

Basic course should focus on a specific topic and then later the
students can try and make a whole out of all the small fragments.

Arne

Basic OS understanding had best be part of a first programming course,
IMO. As for command line/shell, I wouldn't belabour it - not much point
in turning your novices into Powershell or bash experts in the first
semester - but if it's simply pitched as a method of I/O, I can't see
how it interferes more than teaching a GUI.

AHS

 

[Jeff Higgins]

Basic OS understanding had best be part of a first programming course,
IMO. As for command line/shell, I wouldn't belabour it - not much point
in turning your novices into Powershell or bash experts in the first
semester - but if it's simply pitched as a method of I/O, I can't see
how it interferes more than teaching a GUI.

AHS

I keep reading this thread and wondering where Stefan Ram and his
students fit into <http://www.acm.org/education/curricula-recommendations>.

Adult students. Perhaps they all have the core of _CSTA K-12 2011_
and are heading toward one of the "five defined sub-disciplines of
computing" in _Computing Curricula 2005: The Overview Report_.

 

[Stefan Ram]

I keep reading this thread and wondering where Stefan Ram and his
students fit into <http://www.acm.org/education/curricula-recommendations>.

The classes need to have a certain number of reservations.
If there are less reservations, a class will be cancelled.
My beginner and advanced classes in Java and C++ sometimes
have the required number of reservations, so they can take
place sometimes. But there are not enough students to split
the classes into different classes for different types of
students.

(I am willing to teach any programming language as long as
the classes take place. For example, I'd love to teach
Haskell, Groovy, or Scala, you name it. But there will not
be enough reservations. Once, I announced a Perl course, but
there were only 3 reservations, and the class was cancelled.
So essentially, students decide which languages I teach by
attending or not.)

However, the classes clearly state their prerequistes.
The prerequisites for my beginner's programming classes
where set by me as: »Students know how to operate a computer
(copy a file and so), but do not need to know any
programming language.«. If someone already knows a
programming language that's fine, he still can participate,
but should not complain when he hears what he already knows.

 

[Jeff Higgins]

The classes need to have a certain number of reservations.
If there are less reservations, a class will be cancelled.
My beginner and advanced classes in Java and C++ sometimes
have the required number of reservations, so they can take
place sometimes. But there are not enough students to split
the classes into different classes for different types of
students.

(I am willing to teach any programming language as long as
the classes take place. For example, I'd love to teach
Haskell, Groovy, or Scala, you name it. But there will not
be enough reservations. Once, I announced a Perl course, but
there were only 3 reservations, and the class was cancelled.
So essentially, students decide which languages I teach by
attending or not.)

However, the classes clearly state their prerequistes.
The prerequisites for my beginner's programming classes
where set by me as: »Students know how to operate a computer
(copy a file and so), but do not need to know any
programming language.«. If someone already knows a
programming language that's fine, he still can participate,
but should not complain when he hears what he already knows.

Yep. I guess I should have asked "A first course in Java and its'
students" rather than "Stefan Ram and his students". There have
been a lot of "topics in computer science" bantered about. I'm
just trying to get it into some perspective. Lost in the topic drift.

 

[Arved Sandstrom]

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

I keep on coming back to the 30 hours timeframe (12+18) posited by
Stefan. I'm not convinced that most novice students are going to get
anything more from a simple GUI other than some transitory thrill that
it's doable without years of study.

You want to show something that is OO.

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

Swing delivers both.

I suspect you meant *post* 1990.

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.

I am prepared to concede that adequate introductions to those topics
exceeds 30 hours in a semester time frame. I still think that it's
unlikely that you'll squeeze Swing in, in that amount of time, either.

You surely can't *teach* Swing _and_ do an intro to OO in just 30 hours.
You can throw a Swing facade out there about 15-20 hours into it, and
use that as some kind of I/O example, but is that better than dispensing
with a GUI entirely? I stand to be convinced.

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

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

Give people credit, Arne. In any case, this is actually Stefan's call -
and I suppose to some extent the call of the folks who are having him
teach this course. Is he supposed to teach to the small percentage of
newbies that want to become professional programmers, or is it incumbent
on him to satisfy a wider clientele? If it was just the former group,
I'd have no hesitation in being somewhat brutal with the curriculum, and
seeing who can cut it. If it's the latter, maybe I'd concoct a pretty
little Swing GUI.

AHS

 

[Arved Sandstrom]

For an introductory course in programming, I'm not so sure you do.
(Of course, if you use Java as the language you pretty much have
to, but then I'm not sold on Java as a good choice for teaching
programming.)

OO is all about "programming in the large." It's about how to
structure the code to make a large program manageable and
understandable.

Students in an introductory course, though, are still struggling
with "programming in the small" : what a variable is, how to
track program flow, loops and conditionals, what a method or
functional call is, call-by-reference vs. call-by-value,
arrays and data structures, the idea of libraries and using
them, what compilation is, I/O, how to debug and all that
other jazz that seasoned programmers barely even think about.

I think introducing OO concept at this stage (except possibly
as a final "this is where you go from here" at the very end)
would just be so much magical "because that's just how it is"
that'd only serve to distract and confuse the students from
those core concept they really need to focus on.

More than once I've noted how much Java programming is effectively
procedural [1]. I've usually made these comments as a critique, insofar
as someone is claiming to be leveraging objects but really isn't. The
flip side of this criticism is that large portions of an OO program are
necessarily procedural, and there's nothing wrong with that if it's
intentional and justified.

Sticking to Java, we all know that a main() in a "Main" class is much
less OO than it is procedural, and a whole bunch of methods in a typical
Java program are effectively procedural too. One can argue - I certainly
have - that there is often way too much procedural in Java apps, and OO
possibilities are not being leveraged, but that doesn't detract from the
fact that judicious use of procedural in a Java program is perfectly
acceptable. In a typical OO app many of our business logic methods are
really procedures: data-context-interaction (DCI) formalizes this concept.

Having said that, it strikes me that if you're teaching programming with
an OO-capable language, that it's sort of hard to avoid OO, and probably
not desirable. I wouldn't leave it to a final "this is where you go from
here", is what I'm saying. The first time you use a non-primitive
datatype and call a String method, say, or do something with a List or a
Map, I don't know how you avoid discussing either objects or program
flow, honestly. And in some depth, besides.

AHS

 

[Ali Sh]

Many Java classes and Java books teach Java foundations and

then Java OOP to finally be able to show how Swing can be

used to create programs that look like beginners expect

programs to look like, i.e., they do not write some text to

an old-fashioned text console, but run as a GUI windows.



But then, I hear everywhere: �Java on the Desktop is dead.�.

Now I asked myself: Is it wrong to teach how to write Java

desktop applications in a class (using Swing)? After all,

you do not want to waste the time of the students by

teaching them something that is �dead�?

I'm C#.net(web app) programmer and I also begin learning programming with books. I search every book to see new thing and thought I'm in programming until I get job in a Co. and then I see how much I'm dummy in programming.
Programming is to learn basic lang and then get other programmer app and analyse them to learn new issue and programming tip.