Question for Java Gurus

M

Michael K?lling

Mohun Biswas said:
I think it would be more fair to suggest that the metric such people are
using is "the lowest level you MIGHT have to drop down to". ....
By the same token, people who argue that you should learn your way
around outside the GUI are afraid that some day you'll need to do
something the GUI/IDE doesn't handle for you.

I have the impression you are wandering off the original topic of this
discussion.

I don't think (as I read this discussion) that anyone ever argued that
you should not learn to use the command line, not learn compiler
options, not learn the specific internals, etc. I would claim that
every good programmer should definitely know how a compiler works and
how to write assembly language.

But that's not the point.

What we were discussing (or so I thought) is how a beginner should
start to begin learning Java.

It is a pedagogical problem to try to teach too many things _at the
same time_. When I argued to avoid unnecessary detail (such as
compiler options), I was not implying that nobody should learn about
those. Everybody should. But nobody should be required to have to
slough their way through those details while they are trying to learn
to program.

Handling classpath options is a distraction while you are trying to
learn what objects and classes are, and how you structure an OO
program.

The necessity to learn a lot of things does not mean that you have to
learn everything at the same time. In computing education, there is a
'pedagogical patterns' movement (see
http://www.pedagogicalpatterns.org/ and
http://csis.pace.edu/~bergin/#pedpat ). These people collect and
describe successful computing teaching methodology (in a pattern
language), and one of their most popular patterns is 'Early Bird' (see
http://csis.pace.edu/~bergin/PedPat1.3.html ).

'Early Bird' describes a pedagogical technique that is based on
identifying the most important learning goals, and addressing them
early and often.

If you goal is to learn object-oriented programming with Java, then
these goals would have to be understanding objects, classes, methods,
encapsulation and abstraction.

Things like classpaths, compiler options, and even GUI building are
details compared to those.

Sure, Chris Uppal's earlier remark that this does not apply when you
are an experienced programmer who just wants to switch to Java is very
true. That's a different situation.

But Galen Boyer made a remark: "The only problem I see with this
approach is that you've set the expectation that they won't need to
know it. Alot of them will spend the rest of their programming lives
staying away from the guts because their first taste was with
something that "just worked". "

This, I cannot see at all. I have not seen any evidence, either in the
literature or in my work, that supports this one bit. I would like to
know what this statement is based on. (I am working in training
programmers, and have done so for many years, starting from beginners
through to masters and PhD level degrees. I have certainly watched
many students start with an educational environment, and I have never
observed the effect that Galen states there.)

And, of course, I expect people to know the detail at the end. My
students have written compilers and assemblers before they leave our
institution, they have experience in language design, and are
experienced in the construction of OO systems.

Yet they start with a learning environment that hides the Java VM
details.

Regards,

Michael
 
G

Galen Boyer

But Galen Boyer made a remark: "The only problem I see with
this approach is that you've set the expectation that they
won't need to know it. Alot of them will spend the rest of
their programming lives staying away from the guts because
their first taste was with something that "just worked". "

This, I cannot see at all. I have not seen any evidence, either
in the literature or in my work, that supports this one bit.

I see this alot. The very big example of a GUI to command-line
fight is when a windows user is asked to start using Unix, ie,
learning how to be proficient with a command line dominated
environment. Most of them never get past "ls", and they stay
frustrated by the "arcaneness" of it. But, when a Unix user is
asked to learn and use windows, she will and usually becomes
quite skilled at it. This is mostly attributable to the ease of
windows, but my point is that someone who started with the
command-line will usually be comfortable in both worlds, but not
the other way around.

Another analogous example (and directly in the middle of my
profession) is when an entry level Oracle developer starts out
with a GUI tool and not sqlplus, he invariably never gravitates
toward learning how to use sqlplus effectively. He considers it
arcane and hard to use. That becomes a huge hindrance when the
database has been deployed to the production environment and he
is tasked with analyzing why performance is an issue. The only
tool you will be given will be sqlplus. If you start out
learning how to be proficient with the most basic tool, then the
GUI just becomes "another tool". Maybe this is my main issue.
Starting out with a "GUI first" learning approach usually means
you only have one tool type in your professional toolkit.

The windows only user, and this includes developers, comes to
depend on the GUI tool and will have a very hard time when those
tools aren't available, while the command-line user can much more
easily move to a GUI world. Even to the point that if you took
away his command-line and made him only use a GUI, he'd be fine.
Could the same be said of the GUI only user?
I would like to know what this statement is based on. (I am
working in training programmers, and have done so for many
years, starting from beginners through to masters and PhD level
degrees. I have certainly watched many students start with an
educational environment, and I have never observed the effect
that Galen states there.)

I'm not describing effects seen from a professor student
relationship because I don't teach, but instead what I've seen in
professional programming environments. I would bet this, that if
students learn with a GUI, they don't want to and find it a chore
to learn how to program without one. This is why I would suggest
they first learn without one.
And, of course, I expect people to know the detail at the
end. My students have written compilers and assemblers before
they leave our institution, they have experience in language
design, and are experienced in the construction of OO systems.

Well, as long as you make sure they do, then, I think you are
doing the correct thing. My question is, do they gravitate
toward the "I have to bring it all together myself" that you get
in the command-line environment or do you see them considering it
a chore? If its a chore, then you may be doing them a disservice
by starting with a GUI. In the words a teacher would love,
programmers should thirst for understanding everything about
their environments.
 
H

Hank Kester

I mentioned BlueJ in my own reply to the OP, as a possible exception to the
general rule. But, since I haven't actually /used/ it myself (or tried to
teach anyone with it), I can't honestly recommend it -- I /can/ (and do) say
that it's looks promising but I can't claim from personal knowledge that it
delivers on that promise.

As someone who is using BlueJ, has been taught using BlueJ, and has taught
others using BlueJ, I feel it's a very good tool for the job. Of course, I
have an obvious bias, but what can I do? :)

-Hank
 
E

Elspeth Thorne

Michael said:
The question here seems to be the exact line people draw between
accepted abstraction and "magic that keeps you dumb". The problem is
that the real criteria people use to draw this line usually is: the
way I have learned it myself is the only real way to do it.
</snip>

Well.

I'm in a bit of a quandry, here.

I started my programming learning with java, using the GUI on a windows system.
The next year of my university education, I was using gvim on a SunRay.
Concepts-wise, that first year was mostly cut-and-paste; usually from examples
that didn't compile. I learnt a lot from fixing the lecturer's mistakes. The
second year was much the same, except I was producing compile-worthy code away
from computers for much of the assessment, and dealing with a few environmental
issues.

I learnt a bit of syntax, a few data structures, UML, the theory about testing
.... but didn't really understand what it was that I was doing, and
realistically, this 'learning' could have been done in about a month, or perhaps
six weeks, if it had been the only focus of study.

In parallel with this, I was also learning about a couple microprocessors and
their attendant assembly languages. This didn't teach me much about programming
either, except about 'how to fit a complex program in 512 bytes' and 'which pins
to solder to which holes'.

In my third year, things finally started to come together: I learnt about
compilers, and suddenly a few more things made sense. I learnt about functional
and logical programming, and twisted my brain in new and interesting ways. I
learnt about the guts of an operating system. I learnt about networking - and
incidentally about how objects interact with one another in a non-trivial system.

I could finally see what on earth was going on.


A couple of years later, here I am, still learning. But at least now I have a
solid basis from which to build.


In short, I'd have to say that for a new java programmer, who is also new to
programming, you're not going to be able to teach them everything overnight, or
even in a short amount of time. Yes, by all means, start with the GUI, but give
them buggy programs to fix, so that they learn all about errors and what they
mean. Then throw them at the 'primitive' interface, like a vim or an emacs, with
command-line compiling, let them struggle to understand the environment within
which they operate - but after they've sorted the basic language concepts. Then
move on to more complex tasks that require a lot of concept development - lots
of object interaction, compilers, that sort of jazz.


That's my advice, as a recent student of the system.

Elspeth.
 
P

P.Hill

Galen Boyer wrote:

[...]
But, when a Unix user is
asked to learn and use windows, she will and usually becomes
quite skilled at it. This is mostly attributable to the ease of
windows, but my point is that someone who started with the
command-line will usually be comfortable in both worlds, but not
the other way around.
Could the same be said of the GUI only user?

MAYBE it really is because typing memorized commands really is
a very poor way to interact with computers so that going from a
very inefficient and difficult interface (command line) to one that allows one
to be know about, but not know the exact commands (but be able to find them on
some window somewhere) is of course easier for most people.

I'm not impressed with those who think good computer skills is having a bunch of
stuff memorized, even though I have used Unix on and off for years.

But then I did say MAYBE memorized lines of commands is a poor interface.
Obviously, YMMV.

-Paul
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top