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