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 2 of 2 — ← Prev page 1 [2]

#26826

On 12/10/2013 11:07 AM, Stefan Ram wrote:
> Arved Sandstrom <asandstrom2@eastlink.ca> writes:
>>                              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).

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

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

#26909

On 12/10/2013 11:47 AM, Arved Sandstrom wrote:
> On 12/10/2013 11:07 AM, Stefan Ram wrote:
>>    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).

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

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

#26937

On 12/14/2013 07:04 PM, Arne Vajhøj wrote:
> On 12/10/2013 11:47 AM, Arved Sandstrom wrote:
>> On 12/10/2013 11:07 AM, Stefan Ram wrote:
>>>    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).
>
> 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
-- 
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]

#26939

On 12/15/2013 03:58 PM, Arved Sandstrom wrote:
> On 12/14/2013 07:04 PM, Arne Vajhøj wrote:
>> On 12/10/2013 11:47 AM, Arved Sandstrom wrote:
>>> On 12/10/2013 11:07 AM, Stefan Ram wrote:
>>>>    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).
>>
>> 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

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

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

#26941

On 12/15/2013 05:02 PM, Stefan Ram wrote:
> Jeff Higgins <jeff@invalid.invalid> writes:
>> 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.
>
>> 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_.
>
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.

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

#26908

On 12/10/2013 9:22 AM, Arved Sandstrom wrote:
> On 12/09/2013 09:11 PM, Arne Vajhøj wrote:
>> On 12/9/2013 11:02 AM, Arved Sandstrom wrote:
>>> 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?

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.

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

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.

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

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

#26919

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> You want to show something that is OO.

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.

-- 
Leif Roar Moldskred

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

#26922

On 12/15/2013 11:20 AM, Leif Roar Moldskred wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> You want to show something that is OO.
>
> 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.

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

#26926

On 12/15/2013 5:20 AM, Leif Roar Moldskred wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> You want to show something that is OO.
>
> 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

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

#26949

On 12/15/2013 06:20 AM, Leif Roar Moldskred wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> You want to show something that is OO.
>
> 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
-- 
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]

#26942

On 12/14/2013 06:59 PM, Arne Vajhøj wrote:
> On 12/10/2013 9:22 AM, Arved Sandstrom wrote:
>> On 12/09/2013 09:11 PM, Arne Vajhøj wrote:
>>> On 12/9/2013 11:02 AM, Arved Sandstrom wrote:
>>>> 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?
>
> 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.

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

I suspect you meant *post* 1990. :-)

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

-- 
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] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web