Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26798 > unrolled thread

Re: Teaching Java, teaching what?

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Teaching Java, teaching what? Silvio <silvio@internet.com> - 2013-12-09 13:20 +0100
    Re: Teaching Java, teaching what? Silvio <silvio@internet.com> - 2013-12-09 16:17 +0100
      Re: Teaching Java, teaching what? Arne Vajhøj <arne@vajhoej.dk> - 2013-12-09 20:02 -0500
        Re: Teaching Java, teaching what? Silvio <silvio@internet.com> - 2013-12-10 11:56 +0100
          Re: Teaching Java, teaching what? lipska the kat <"lipskathekat at yahoo dot co dot uk"> - 2013-12-10 12:07 +0000
            Re: Teaching Java, teaching what? Silvio <silvio@internet.com> - 2013-12-10 13:39 +0100
              Re: Teaching Java, teaching what? lipska the kat <"lipskathekat at yahoo dot co dot uk"> - 2013-12-10 12:56 +0000
                Re: Teaching Java, teaching what? Silvio <silvio@internet.com> - 2013-12-10 14:38 +0100
            Re: Teaching Java, teaching what? Arne Vajhøj <arne@vajhoej.dk> - 2013-12-14 20:05 -0500
          Re: Teaching Java, teaching what? Arne Vajhøj <arne@vajhoej.dk> - 2013-12-14 19:58 -0500
            Re: Teaching Java, teaching what? Joerg Meier <joergmmeier@arcor.de> - 2013-12-15 03:49 +0100
            Re: Teaching Java, teaching what? Silvio <silvio@internet.com> - 2013-12-15 11:29 +0100
              Re: Teaching Java, teaching what? lipska the kat <"lipskathekat at yahoo dot co dot uk"> - 2013-12-15 10:55 +0000
            Re: Teaching Java, teaching what? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-15 16:54 -0400
    Re: Teaching Java, teaching what? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-09 12:02 -0400
      Re: Teaching Java, teaching what? Martin Gregorie <martin@address-in-sig.invalid> - 2013-12-09 21:49 +0000
      Re: Teaching Java, teaching what? Arne Vajhøj <arne@vajhoej.dk> - 2013-12-09 20:11 -0500
        Re: Teaching Java, teaching what? markspace <markspace@nospam.nospam> - 2013-12-09 17:58 -0800
        Re: Teaching Java, teaching what? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-10 10:22 -0400
          Re: Teaching Java, teaching what? Jeff Higgins <jeff@invalid.invalid> - 2013-12-10 11:02 -0500
          Re: Teaching Java, teaching what? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-10 12:47 -0400
            Re: Teaching Java, teaching what? Arne Vajhøj <arne@vajhoej.dk> - 2013-12-14 18:04 -0500
              Re: Teaching Java, teaching what? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-15 16:58 -0400
                Re: Teaching Java, teaching what? Jeff Higgins <jeff@invalid.invalid> - 2013-12-15 16:36 -0500
                  Re: Teaching Java, teaching what? Jeff Higgins <jeff@invalid.invalid> - 2013-12-15 18:17 -0500
          Re: Teaching Java, teaching what? Arne Vajhøj <arne@vajhoej.dk> - 2013-12-14 17:59 -0500
            Re: Teaching Java, teaching what? leif.roar@invalid.com (Leif Roar Moldskred) - 2013-12-15 04:20 -0600
              Re: Teaching Java, teaching what? Silvio <silvio@internet.com> - 2013-12-15 12:23 +0100
              Re: Teaching Java, teaching what? Arne Vajhøj <arne@vajhoej.dk> - 2013-12-15 10:00 -0500
              Re: Teaching Java, teaching what? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-16 10:28 -0400
            Re: Teaching Java, teaching what? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-15 21:32 -0400

Page 1 of 2  [1] 2  Next page →

#26798 — Re: Teaching Java, teaching what?

On 12/08/2013 05:00 PM, Stefan Ram wrote:
>    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«?
>

Why not have them write a simple Servlet or two? Teach them some very 
basic HTML/CSS tricks for their second or third Servlet (as opposed to 
plain text) and I am sure you get people interested.
If you embed a Servlet container (Jetty comes to mind) they can all run 
their own application locally and test it from their browser.

IMHO you should either go mobile or HTML(5). I know there are crowds 
clinging to Applet/Desktop/Swing/JavaFX etc. but it does not sound as a 
logical choice for an introductory course.

Silvio

[toc] | [next] | [standalone]

#26803

On 12/09/2013 02:34 PM, Stefan Ram wrote:
> Silvio <silvio@internet.com> writes:
>> Why not have them write a simple Servlet or two?
>
>    The time for teaching is very limited: I now often have only
>    30 hours to take students from »no programming experience
>    whatsoever« to »first steps with Swing« including exercises
>    done in the classroom. When teaching Java with Swing, I need
>    the JDK as the one single dependency: javac Main.java, java
>    Main, and that's it.
>
>    I have the impression that teaching servlets is more
>    time-consuming, because the toolchain is longer and the
>    configuration and application of more tools needs to be done
>    and explained.
>

If you sufficiently wrap the embedded container inside a utility class 
the toolchain becomes quite short and all the students would do is 
define a Servlet class implementing a doGet method. They would need to 
know some basics about a HTTPServletResponse but I suspect getting 
started with even the most basic Swing stuff requires more knowledge 
upfront.

On the other hand you would have to set up their environments with some 
additional JARs so that might be a problem, especially if they intend to 
take the fruits of their work home.

[toc] | [prev] | [next] | [standalone]

#26807

On 12/9/2013 10:17 AM, Silvio wrote:
> On 12/09/2013 02:34 PM, Stefan Ram wrote:
>> Silvio <silvio@internet.com> writes:
>>> Why not have them write a simple Servlet or two?
>>
>>    The time for teaching is very limited: I now often have only
>>    30 hours to take students from »no programming experience
>>    whatsoever« to »first steps with Swing« including exercises
>>    done in the classroom. When teaching Java with Swing, I need
>>    the JDK as the one single dependency: javac Main.java, java
>>    Main, and that's it.
>>
>>    I have the impression that teaching servlets is more
>>    time-consuming, because the toolchain is longer and the
>>    configuration and application of more tools needs to be done
>>    and explained.
>>
>
> If you sufficiently wrap the embedded container inside a utility class
> the toolchain becomes quite short and all the students would do is
> define a Servlet class implementing a doGet method. They would need to
> know some basics about a HTTPServletResponse but I suspect getting
> started with even the most basic Swing stuff requires more knowledge
> upfront.

A desktop app is very standalone.

Web means:
- two apps: browser and server
- knowledge of at least HTML required (CSS and JS optional)
- a little bit of knowledge about HTTP and the interaction

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

Arne

[toc] | [prev] | [next] | [standalone]

#26818

On 12/10/2013 02:02 AM, Arne Vajhøj wrote:
> 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.


>
> Arne
>

[toc] | [prev] | [next] | [standalone]

#26819

On 10/12/13 10:56, Silvio wrote:
> On 12/10/2013 02:02 AM, Arne Vajhøj wrote:
>> 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.

Spot on. *Web development* is actually a misnomer. I prefer 'web 
interface'. The 'OO'ness of something shouldn't depend 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.

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.

FWIW

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?


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26820

On 12/10/2013 01:07 PM, lipska the kat wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#26821

On 10/12/13 12:39, Silvio wrote:
> On 12/10/2013 01:07 PM, lipska the kat wrote:
>> On 10/12/13 10:56, Silvio wrote:

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

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?

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26822

On 12/10/2013 01:56 PM, lipska the kat wrote:
> On 10/12/13 12:39, Silvio wrote:
>> On 12/10/2013 01:07 PM, lipska the kat wrote:
>>> On 10/12/13 10:56, Silvio wrote:
>
>> 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.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#26911

On 12/10/2013 7:07 AM, lipska the kat wrote:
> On 10/12/13 10:56, Silvio wrote:
>> On 12/10/2013 02:02 AM, Arne Vajhøj wrote:
>>> 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.
>
> 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

[toc] | [prev] | [next] | [standalone]

#26910

On 12/10/2013 5:56 AM, Silvio wrote:
> On 12/10/2013 02:02 AM, Arne Vajhøj wrote:
>> 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

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

[toc] | [prev] | [next] | [standalone]

#26916

On Sat, 14 Dec 2013 19:58:39 -0500, Arne Vajhøj wrote:

>>            layout managers,
> 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

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#26920

On 12/15/2013 01:58 AM, Arne Vajhøj wrote:
> On 12/10/2013 5:56 AM, Silvio wrote:
>> On 12/10/2013 02:02 AM, Arne Vajhøj wrote:
>>> 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
>
> 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
>

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.

[toc] | [prev] | [next] | [standalone]

#26921

On 15/12/13 10:29, Silvio wrote:
> On 12/15/2013 01:58 AM, Arne Vajhøj wrote:
>> On 12/10/2013 5:56 AM, Silvio wrote:
>>> On 12/10/2013 02:02 AM, Arne Vajhøj wrote:
>>>> 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
>>
>> 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
>>
>
> 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.

I've discovered that it's not really worth arguing with Arne about OO. 
He doesn't really 'get it'. But kudos for trying.


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26936

On 12/14/2013 08:58 PM, Arne Vajhøj wrote:
> On 12/10/2013 5:56 AM, Silvio wrote:
>> On 12/10/2013 02:02 AM, Arne Vajhøj wrote:
>>> 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
>
> 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
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#26804

On 12/09/2013 09:34 AM, Stefan Ram wrote:
> Silvio <silvio@internet.com> writes:
>> Why not have them write a simple Servlet or two?
>
>    The time for teaching is very limited: I now often have only
>    30 hours to take students from »no programming experience
>    whatsoever« to »first steps with Swing« including exercises
>    done in the classroom. When teaching Java with Swing, I need
>    the JDK as the one single dependency: javac Main.java, java
>    Main, and that's it.
>
>    I have the impression that teaching servlets is more
>    time-consuming, because the toolchain is longer and the
>    configuration and application of more tools needs to be done
>    and explained.
>
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. 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...but I myself have a gut feeling that you'd do better with a 
servlet approach.

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.

AHS
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#26805

On Mon, 09 Dec 2013 12:02:53 -0400, Arved Sandstrom wrote:

> 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.
>
That makes sense to me, and might even free up a little time to teach the 
use of sockets implement a simple client/server pair and/or the use of 
JDBC to access a simple database such as a simple schema supported by 
Derby. The concepts behind both suggestions are pretty straight forward, 
IMO rather more so than using a GUI.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#26808

On 12/9/2013 11:02 AM, Arved Sandstrom wrote:
> On 12/09/2013 09:34 AM, Stefan Ram wrote:
>> Silvio <silvio@internet.com> writes:
>>> Why not have them write a simple Servlet or two?
>>
>>    The time for teaching is very limited: I now often have only
>>    30 hours to take students from »no programming experience
>>    whatsoever« to »first steps with Swing« including exercises
>>    done in the classroom. When teaching Java with Swing, I need
>>    the JDK as the one single dependency: javac Main.java, java
>>    Main, and that's it.
>>
>>    I have the impression that teaching servlets is more
>>    time-consuming, because the toolchain is longer and the
>>    configuration and application of more tools needs to be done
>>    and explained.
>>
> 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

[toc] | [prev] | [next] | [standalone]

#26812

On 12/9/2013 5:11 PM, Arne Vajhøj wrote:

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

[toc] | [prev] | [next] | [standalone]

#26823

On 12/09/2013 09:11 PM, Arne Vajhøj wrote:
> On 12/9/2013 11:02 AM, Arved Sandstrom wrote:
>> On 12/09/2013 09:34 AM, Stefan Ram wrote:
>>> Silvio <silvio@internet.com> writes:
>>>> Why not have them write a simple Servlet or two?
>>>
>>>    The time for teaching is very limited: I now often have only
>>>    30 hours to take students from »no programming experience
>>>    whatsoever« to »first steps with Swing« including exercises
>>>    done in the classroom. When teaching Java with Swing, I need
>>>    the JDK as the one single dependency: javac Main.java, java
>>>    Main, and that's it.
>>>
>>>    I have the impression that teaching servlets is more
>>>    time-consuming, because the toolchain is longer and the
>>>    configuration and application of more tools needs to be done
>>>    and explained.
>>>
>> 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.

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

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

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.

>>    but I myself have a gut feeling that you'd do better with a
>> servlet approach.
>
> 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.

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

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.
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#26825

On 12/10/2013 10:07 AM, Stefan Ram wrote:
>    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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web